Automating Windows Server Core Installation with PowerShell DSC

Windows Server Core gives infrastructure teams a small-footprint operating system that still exposes PowerShell, WinRM and Windows management APIs. For Australian administrators supporting VMware estates alongside cloud instances, that combination makes repeatable configuration practical. The aim is a recoverable process that produces the same roles, files and settings on every host.

PowerShell DSC expresses those outcomes as desired state. The Local Configuration Manager tests the current state, applies only necessary changes and reports drift, giving Server Core fleets the same declarative discipline used for files, registry values and Windows features. It is particularly useful after imaging, when servers must be joined, hardened and prepared for application workloads without a graphical interface.

A reliable unattended workflow has two layers: media and answer files create a bootable Server Core installation, then DSC handles post-install configuration. DSC cannot format bare metal or install Windows onto a disk containing no operating system. Keeping those responsibilities separate makes the image repeatable while placing changing requirements in one testable baseline.

Prepare a repeatable deployment image

Start with supported Windows Server media and an organisation-specific answer file. It can select the Server Core image, set Australian English and the AUS Eastern Standard Time zone, and define a first-boot action. Avoid reusable local administrator passwords in XML; prefer domain or certificate-based access for managed fleets.

Apply the image-specific portion of the answer file to a mounted image, then save the result. Version the WIM and XML together and deploy it through VMware, bare-metal or cloud provisioning. Copy the bootstrap script into the image or provisioning payload, and record its exit code.

New-Item -ItemType Directory -Path C:\Mount,D:\Scratch -Force

Mount-WindowsImage -ImagePath D:\Sources\install.wim -Index 1 `
    -Path C:\Mount -ScratchDirectory D:\Scratch

dism.exe /Image:C:\Mount /Apply-Unattend:D:\AnswerFiles\CoreImage.xml

Dismount-WindowsImage -Path C:\Mount -Save

Bootstrap remote management

On the first boot, confirm that Windows PowerShell 5.1 and the PSDesiredStateConfiguration module are present. For a conservative production baseline, use the in-box Windows DSC implementation rather than depending on a preview cross-platform release; PowerShell 7 on Linux is not a drop-in LCM for Server Core nodes.

WinRM must be available before an administrator can push a configuration. A SYSTEM-run bootstrap script can enable PS remoting, while the deployment mechanism handles domain join and local policy. The connecting account must be a member of the local Administrators group on each node. Restrict ports 5985 and 5986 to management networks, and use HTTPS or Group Policy message protection rather than exposing WinRM to the internet.

Enable-PSRemoting -SkipNetworkProfileCheck -Force

Build the desired-state baseline

A baseline should cover the roles and features required by each workload, plus directories, registry values and operational settings. Applying an unchanged baseline produces no change, while a missing file or removed feature is detected as drift.

Consideration	Push mode	Pull mode
Control point	An operator or controller sends the compiled configuration	The node LCM polls a management endpoint
Timing	Immediate, using -Wait	Scheduled polling or startup
Connectivity	The controller reaches the node over WinRM	The node makes an outbound connection
Typical fit	Controlled on-premises estates and small fleets	Regional offices, cloud networks and remote sites

This example installs File Services and creates a standard audit location. Replace the node list and feature names with the workload’s requirements instead of treating the sample as a universal baseline.

Configuration CoreBaseline {
    Node $AllNodes.NodeName {
        Import-DscResource -ModuleName PSDesiredStateConfiguration

        WindowsFeature FileServer {
            Name = 'FS-FileServer'
            Ensure = 'Present'
        }

        File AuditDirectory {
            DestinationPath = 'C:\ProgramData\ITDiversified\Logs'
            Directory = $true
            Ensure = 'Present'
        }

        Registry AuditSetting {
            Key = 'HKLM:\SOFTWARE\ITDiversified'
            ValueName = 'AuditPath'
            ValueData = 'C:\ProgramData\ITDiversified\Logs'
            ValueType = 'String'
            Ensure = 'Present'
        }
    }
}

WindowsFeature is appropriate for supported roles and optional features, but some installations require a restart and leave the node pending reboot. Monthly patching and application packages usually belong in WSUS, Intune or Configuration Manager, where reboot coordination and package servicing are better suited than a DSC feature resource.

Apply and verify the configuration

Compile the configuration locally, then push it with a PSCredential or certificate-backed identity. The -Wait parameter prevents automation from continuing while the LCM is still applying resources.

$configData = @{
    AllNodes = @(
        @{ NodeName = 'core-syd-01' }
    )
}

CoreBaseline -ConfigurationData $configData

$credential = Get-Credential

Start-DscConfiguration -Path .\CoreBaseline `
    -ComputerName 'core-syd-01' `
    -Credential $credential -Wait -Verbose

Run Test-DscConfiguration against the same reference, then inspect Get-DscConfigurationStatus and the Microsoft-Windows-DSC/Operational event channel when a node is inconsistent. A second run should show no resource changes. For larger fleets, invoke the push from an orchestrator or use pull mode so nodes retrieve approved configurations on a schedule.

Secure and operate the fleet

Use the baseline to support, rather than replace, controls aligned with the Australian Signals Directorate’s Essential Eight. DSC can enforce selected configuration, but patching, multifactor authentication, application control, backups and privileged access remain separate controls. Protect credential-bearing MOFs and diagnostic output. Organisations covered by the Privacy Act 1988 and the Notifiable Data Breaches scheme should treat node inventories, paths and error reports as operational metadata that could expose system or personal information.

A common Australian hybrid pattern combines on-premises VMware with Windows workloads in Azure and AWS. Push mode fits a controlled data-centre estate; pull mode often suits cloud nodes or regional offices because the node makes an outbound connection to an internal management endpoint. Give every node a deterministic identity and unique certificate. Sydney and Melbourne support teams commonly work across AEST and AEDT, so schedule role installation and reboots in deliberate after-hours windows, account for daylight-saving changes and retain UTC timestamps in central logs. That approach keeps each installation repeatable and auditable across local and cloud infrastructure.