Windows Server Administration Questions

Direct answer

Fan out with PowerShell remoting (sending the same job to many servers at once, over WinRM, the Windows Remote Management protocol that PowerShell remoting uses), but make each server do its own measuring. Invoke-Command -AsJob sends one script block to every server (at most 32 connections at once by default, tunable with -ThrottleLimit), the block reads counters and events locally, and only a small summary object per server comes back. Reliability comes from four things: batches, a hard deadline per batch, a status row for every server (including the ones that did not answer), and one retry pass. Credentials are never typed or stored: the scheduled task runs as a group Managed Service Account (gMSA, an Active Directory account whose password the domain controllers generate and rotate automatically), so remoting uses Kerberos (the domain's ticket-based sign-in protocol, where no password crosses the network) with no secret in the script.

Design decisions

The script

#Requires -Version 5.1
[CmdletBinding()]
param(
    [Parameter(Mandatory)][string]$ServerListPath,
    [string]$OutputDirectory = 'D:\Reports\NightlyHealth',
    [int]$ThrottleLimit = 32,
    [int]$BatchSize = 100,
    [int]$ConnectTimeoutSec = 30,
    [int]$BatchDeadlineSec = 600,
    [int]$EventLookbackHours = 24,
    [string[]]$ExtraCounterPath = @(),
    [double]$CpuAlertPct = 90,
    [double]$MemFreeAlertMB = 1024,
    [double]$DiskQueueAlert = 2,
    [int]$ErrorEventAlert = 25,
    [double]$MaxFailurePct = 10
)

# Runs ON each target, so the counters and events are read locally and only
# one small object per server crosses the network.
$collect = {
    param([int]$LookbackHours, [string[]]$Extra)
    $Extra = @($Extra | Where-Object { $_ })
    $paths = @(
        '\Processor(_Total)\% Processor Time',
        '\Memory\Available MBytes',
        '\PhysicalDisk(_Total)\Avg. Disk Queue Length',
        '\Network Interface(*)\Bytes Total/sec'
    ) + @($Extra)
    $sets = @(Get-Counter -Counter $paths -SampleInterval 5 -MaxSamples 3 -ErrorAction Stop)
    $average = {
        param($like)
        ($sets | ForEach-Object { $_.CounterSamples } |
            Where-Object { $_.Path -like $like } |
            Measure-Object -Property CookedValue -Average).Average
    }
    $netPerSet = $sets | ForEach-Object {
        ($_.CounterSamples | Where-Object { $_.Path -like '*network interface(*)\bytes total/sec' } |
            Measure-Object -Property CookedValue -Sum).Sum
    }
    $extraText = @($Extra | ForEach-Object {
        $mean = (& $average ('*' + $_.ToLower()))
        '{0}={1}' -f $_, [math]::Round($mean, 2)
    }) -join '; '
    $cap = 1000
    $since = (Get-Date).AddHours(-$LookbackHours)
    $evErr = $null
    $events = @(Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application'; Level = 1, 2; StartTime = $since } `
        -MaxEvents $cap -ErrorAction SilentlyContinue -ErrorVariable evErr)
    # "No events found" is a normal answer; any other error (for example access denied) must not look like zero events.
    $evProblem = (@($evErr | Where-Object { $_.Exception.Message -notmatch 'No events were found' } |
        ForEach-Object { $_.Exception.Message }) -join ' | ')
    $top = $events | Group-Object -Property ProviderName | Sort-Object -Property Count -Descending |
        Select-Object -First 3 | ForEach-Object { '{0} x{1}' -f $_.Name, $_.Count }
    [pscustomobject]@{
        CpuPct          = [math]::Round((& $average '*\processor(_total)\% processor time'), 1)
        MemFreeMB       = [math]::Round((& $average '*\memory\available mbytes'), 0)
        DiskQueue       = [math]::Round((& $average '*\physicaldisk(_total)\avg. disk queue length'), 2)
        NetBytesPerSec  = [math]::Round((($netPerSet | Measure-Object -Average).Average), 0)
        ErrorEvents     = $events.Count
        EventsCapped    = ($events.Count -ge $cap)
        TopSources      = ($top -join '; ')
        Extra           = $extraText
        EventQueryError = $evProblem
    }
}

function Get-HealthFlag {
    param([Parameter(Mandatory)]$Row)
    $flags = @()
    if ($Row.Status -ne 'Ok') { return @("Status=$($Row.Status)") }
    if ($Row.CpuPct -ge $CpuAlertPct)           { $flags += 'CPU' }
    if ($Row.MemFreeMB -le $MemFreeAlertMB)     { $flags += 'Memory' }
    if ($Row.DiskQueue -ge $DiskQueueAlert)     { $flags += 'DiskQueue' }
    if ($Row.ErrorEvents -ge $ErrorEventAlert)  { $flags += 'ErrorEvents' }
    if ($Row.EventQueryError)                   { $flags += 'EventQuery' }
    $flags
}

function Invoke-HealthBatch {
    param([string[]]$ComputerName)
    $so = New-PSSessionOption -OpenTimeout ($ConnectTimeoutSec * 1000)
    $job = Invoke-Command -ComputerName $ComputerName -ScriptBlock $collect `
        -ArgumentList $EventLookbackHours, $ExtraCounterPath -ThrottleLimit $ThrottleLimit `
        -SessionOption $so -AsJob
    $null = Wait-Job -Job $job -Timeout $BatchDeadlineSec
    foreach ($child in $job.ChildJobs) {
        # Every row starts with the same columns, so Export-Csv (which takes its columns from the first row) keeps them all.
        $row = [ordered]@{
            Server = $child.Location; Status = 'Ok'; Detail = ''
            CpuPct = $null; MemFreeMB = $null; DiskQueue = $null; NetBytesPerSec = $null
            ErrorEvents = $null; EventsCapped = $null; TopSources = ''; Extra = ''; EventQueryError = ''
        }
        switch ($child.State) {
            'Completed' {
                $data = Receive-Job -Job $child -ErrorAction SilentlyContinue
                if ($null -eq $data) { $row.Status = 'NoData' }
                else { foreach ($p in $data.PSObject.Properties) { if ($p.Name -notlike 'PS*' -and $p.Name -ne 'RunspaceId') { $row[$p.Name] = $p.Value } } }
            }
            'Failed' {
                $row.Status = 'Failed'
                $row.Detail = [string]$child.JobStateInfo.Reason.Message
            }
            default {
                Stop-Job -Job $child
                $row.Status = 'TimedOut'
            }
        }
        [pscustomobject]$row
    }
    Remove-Job -Job $job -Force
}

$servers = @(Get-Content -LiteralPath $ServerListPath |
    ForEach-Object { $_.Trim() } |
    Where-Object { $_ -and -not $_.StartsWith('#') } |
    Sort-Object -Unique)

$rows = [System.Collections.Generic.List[object]]::new()
for ($i = 0; $i -lt $servers.Count; $i += $BatchSize) {
    $last = [math]::Min($i + $BatchSize, $servers.Count) - 1
    foreach ($r in (Invoke-HealthBatch -ComputerName $servers[$i..$last])) { $rows.Add($r) }
}

# One retry pass for servers that failed or timed out, in case of a transient network or WinRM hiccup.
$retry = @($rows | Where-Object { $_.Status -in 'Failed', 'TimedOut', 'NoData' } | ForEach-Object { $_.Server })
if ($retry.Count -gt 0) {
    $second = @(Invoke-HealthBatch -ComputerName $retry)
    foreach ($r in $second) {
        $old = $rows | Where-Object { $_.Server -eq $r.Server } | Select-Object -First 1
        if ($null -ne $old) { [void]$rows.Remove($old) }
        $rows.Add($r)
    }
}

foreach ($r in $rows) {
    $r | Add-Member -NotePropertyName Flags -NotePropertyValue ((Get-HealthFlag -Row $r) -join ',') -Force
}

New-Item -ItemType Directory -Path $OutputDirectory -Force | Out-Null
$stamp = Get-Date -Format 'yyyyMMdd'
$rows | Sort-Object -Property Server |
    Export-Csv -LiteralPath (Join-Path $OutputDirectory "health-$stamp.csv") -NoTypeInformation
$rows | Where-Object { $_.Flags } |
    Export-Csv -LiteralPath (Join-Path $OutputDirectory "alerts-$stamp.csv") -NoTypeInformation

$summary = [pscustomobject]@{
    Date       = $stamp
    Total      = $rows.Count
    Collected  = @($rows | Where-Object Status -eq 'Ok').Count
    Failed     = @($rows | Where-Object Status -ne 'Ok').Count
    Flagged    = @($rows | Where-Object { $_.Flags -and $_.Status -eq 'Ok' }).Count
}
$summary | ConvertTo-Json | Set-Content -LiteralPath (Join-Path $OutputDirectory "summary-$stamp.json")

# A non-zero exit code lets the scheduler show a failed run when too much of the estate was unreachable.
if ($summary.Total -gt 0 -and (100 * $summary.Failed / $summary.Total) -gt $MaxFailurePct) { exit 2 }

How the script works, piece by piece.

• $collect = { ... } stores a block of code in a variable (a script block) so it can be sent to the servers later. Its param(...) line receives the values passed with -ArgumentList. Everything inside runs on the target, so the counters and events are read locally.
• $average = { param($like) ... } is a script block used like a small function. Later & $average '<pattern>' runs it (& is the call operator, which runs a script block). It filters the collected counter samples by a wildcard on their path and returns the mean of their values. The patterns are lower case because counter paths come back lower case.
• -ErrorAction SilentlyContinue -ErrorVariable evErr on Get-WinEvent hides errors on screen but still stores them in $evErr, so the script can tell "no events found" (normal) from "access denied" (a problem).
• Invoke-HealthBatch starts one Invoke-Command -AsJob. That returns a parent job with one child job per server (ChildJobs). Wait-Job -Timeout waits up to the batch deadline. Then each child is judged by its State: Completed means read its result with Receive-Job, Failed means record the reason text, anything else is still running past the deadline, so it is stopped and marked TimedOut.
• Each row is created with the same columns up front. Export-Csv takes its column list from the first row it sees, so without that, a server that failed (which has no measurements) sorting first would strip every measurement column from the whole file. This was checked by running both versions against stand-in data.
• The for loop slices the server list into batches of 100. The retry block then re-runs only the servers whose status is not Ok and replaces their rows. The CSV, JSON and exit code come after the retry, so they describe the final state.

Output from a run of this script against stand-in Invoke-Command, Receive-Job and related functions with four made-up servers (db01 fails to connect, fs01 never finishes, web01 has 37 error events, web02 is quiet). Real output of that run; the long error text is trimmed to ...:

health-<date>.csv
"Server","Status","Detail","CpuPct","MemFreeMB","DiskQueue","NetBytesPerSec","ErrorEvents","EventsCapped","TopSources","Extra","EventQueryError","Flags"
"db01","Failed","Connecting to remote server db01 failed ...",,,,,,,"","","","Status=Failed"
"fs01","TimedOut","",,,,,,,"","","","Status=TimedOut"
"web01","Ok","","60","1800","0.4","2400000","37","False","Microsoft-Windows-DistributedCOM x20; Schannel x9; Service Control Manager x8","","","ErrorEvents"
"web02","Ok","","12.5","6200","0.05","310000","2","False","Schannel x2","","",""

summary-<date>.json
{
  "Date": "<date>",
  "Total": 4,
  "Collected": 2,
  "Failed": 2,
  "Flagged": 1
}

exit code: 2

Reading it: unreachable servers are rows with a Status and an empty set of measurements, so they cannot be mistaken for healthy ones. web01 is flagged only for ErrorEvents (37 is at or above the threshold of 25). Two of four servers are 50 percent unmeasured, above the 10 percent limit, so the exit code is 2.

What it produces each night: health-<date>.csv (one row per server), alerts-<date>.csv (rows with at least one flag), and summary-<date>.json (Total, Collected, Failed, Flagged). It exits with code 2 when more than MaxFailurePct of the list could not be measured, so the scheduler shows a failed run instead of a green run with an empty report.

Credentials and permissions

Create the gMSA once and let it run the task. The forest needs a KDS root key first: the master key the domain controllers use to generate gMSA passwords. It is created once per forest with Add-KdsRootKey (Learn: it is required to run only once per forest), and Learn says the domain controllers wait up to 10 hours from its creation before allowing a gMSA to be created, so that every controller has converged on the key. Then create the account, let the collector's computer account retrieve its password, and install and test it on the collector (the group name and DNS name here are illustrative):

New-ADServiceAccount -Name 'svc-health' -DNSHostName 'svc-health.contoso.com' -PrincipalsAllowedToRetrieveManagedPassword 'Health-Collectors'
Install-ADServiceAccount -Identity 'svc-health'   # run on the collector server
Test-ADServiceAccount -Identity 'svc-health'

The task itself is registered like this:

$action    = New-ScheduledTaskAction -Execute 'powershell.exe' `
    -Argument '-NoProfile -File C:\Ops\Get-NightlyHealth.ps1 -ServerListPath C:\Ops\servers.txt'
$trigger   = New-ScheduledTaskTrigger -Daily -At '01:30'
$principal = New-ScheduledTaskPrincipal -UserId 'CONTOSO\svc-health$' -LogonType Password
Register-ScheduledTask -TaskName 'Nightly server health' -Action $action -Trigger $trigger -Principal $principal

Microsoft documents scheduled tasks as a supported use of a gMSA. On the targets, the account needs three things and does not need local administrator rights, which limits what a stolen task could do. First, permission to connect to the PowerShell remoting endpoint over WinRM (TCP 5985, or 5986 for HTTPS): the endpoint's security descriptor (the access list stored on the endpoint, saying who may use it) must give the account at least the Execute(Invoke) permission, meaning the right to run commands through it. Microsoft's remoting requirements name membership in the Remote Management Users local group as the non-administrator route, but they also state that the default endpoint descriptor admits only Administrators, so check one server with Get-PSSessionConfiguration -Name Microsoft.PowerShell and adjust with Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI before rolling out. Second, membership in Performance Monitor Users, to read counters. Third, membership in Event Log Readers, to read the System and Application logs. Deliver the group memberships with a Group Policy preference.

Worked example: an estate of 400 servers

• 400 servers in batches of 100 gives 4 batches. With at most 32 connections at once, a batch of 100 keeps the pool busy through at least ceil(100 / 32) = 4 waves of connections.
• Suppose 45 servers are still failing after the retry pass. That is 45 / 400 = 11.25 percent, above the 10 percent default, so the run exits with code 2 and the report lists the 45 servers with their Detail text. The retry pass has already happened by this point: the script re-runs every non-Ok server once, replaces their rows, and only then writes the files and checks the failure percentage, so the 45 are the servers still unmeasured after the retry.
• A server whose three CPU samples are 40, 60 and 80 percent reports CpuPct 60 (below the 90 threshold). Free memory samples of 2000, 1800 and 1600 MB report MemFreeMB 1800 (above the 1024 floor). If it logged 37 error events in the last 24 hours, that is at or above the threshold of 25, so the row is flagged ErrorEvents and only that.

Alerting

Flagged rows go to the alerts file. For email, do not use Send-MailMessage: Microsoft marks it obsolete because it cannot guarantee a secure SMTP connection. Use Send-MgUserMail from the Microsoft Graph PowerShell SDK if the mailbox is in Exchange Online, or the MailKit library otherwise, authenticated as the same gMSA or a service identity with send rights to a single mailbox.

Trade-offs and pitfalls

• Counter names are localized. \Processor(_Total)\% Processor Time fails on a server with a non-English display language; run Get-Counter -ListSet Processor on one such server before adding it to the list.
• -ErrorAction SilentlyContinue on Get-WinEvent hides the normal "no events found" answer, which is why the script captures -ErrorVariable and reports any other error (for example access denied) in EventQueryError and as the EventQuery flag. Without that, a missing permission looks like a healthy server.
• The event query stops at 1000 events per server; EventsCapped says when that happened, so a count of 1000 is read as "at least 1000".
• A threshold on one night is a weak signal. Trend the CSVs and alert on a server that is flagged on three nights in a row, rather than paging on a single sample.
• The aggregation and the job-state handling can be tested away from production by defining stand-ins named Get-Counter, Get-WinEvent and Invoke-Command that return canned objects and jobs, then running the unchanged script block and function.

Direct answer

The script manages three things: the DNS Server role, the zone example.local, and the server-level forwarders. A forwarder is another DNS server that this server hands queries to when it cannot answer them itself. Before each change it asks a read-only question about the current state and acts only when the answer is "not as desired". That makes it idempotent, meaning a second run changes nothing. You verify it three ways: query the three resources, resolve a name through the server, and run the script with -WhatIf, which prints no "What if" line on a converged server.

The script

[CmdletBinding(SupportsShouldProcess)]
param(
    [string]$ZoneName = 'example.local',
    [string[]]$Forwarders = @('8.8.8.8', '1.1.1.1')
)
$ErrorActionPreference = 'Stop'
$changes = 0

# 1. Role: install only when Get-WindowsFeature says it is missing.
if (-not (Get-WindowsFeature -Name DNS).Installed) {
    if ($PSCmdlet.ShouldProcess('DNS Server role', 'Install')) {
        Install-WindowsFeature -Name DNS -IncludeManagementTools | Out-Null
        $changes++
    }
}
if (-not (Get-WindowsFeature -Name DNS).Installed) {
    if ($WhatIfPreference) { Write-Output 'Dry run: role not installed, stopping here.'; return }
    throw 'DNS Server role is still missing after Install-WindowsFeature.'
}

# 2. Zone: list what the server really has, then test membership.
$zoneExists = [bool](Get-DnsServerZone | Where-Object { $_.ZoneName -eq $ZoneName })
if (-not $zoneExists) {
    if ($PSCmdlet.ShouldProcess($ZoneName, 'Create file-backed primary zone')) {
        Add-DnsServerPrimaryZone -Name $ZoneName -ZoneFile "$ZoneName.dns"
        $changes++
    }
}

# 3. Forwarders: compare as sets, because the server may reorder them.
$current = @((Get-DnsServerForwarder).IPAddress | ForEach-Object { "$_" })
$missing = @($Forwarders | Where-Object { $_ -notin $current })
$extra   = @($current    | Where-Object { $_ -notin $Forwarders })
if ($missing.Count -gt 0 -or $extra.Count -gt 0) {
    if ($PSCmdlet.ShouldProcess('DNS forwarders', "Set to $($Forwarders -join ', ')")) {
        Set-DnsServerForwarder -IPAddress $Forwarders
        $changes++
    }
}

Write-Output "Changes made: $changes"

A zone is the slice of the DNS namespace this server answers for authoritatively, meaning its records are the final answer rather than a copy relayed from elsewhere. This one is file-backed, stored in a zone file named example.local.dns. Run it elevated, because Install-WindowsFeature requires an elevated session.

How -WhatIf works in this script

[CmdletBinding(SupportsShouldProcess)] gives the script the standard -WhatIf and -Confirm switches. Each change sits inside if ($PSCmdlet.ShouldProcess(target, action)). On a normal run ShouldProcess returns True and the change happens. With -WhatIf it prints a line beginning What if: and returns False, so the change is skipped. $WhatIfPreference is True during a -WhatIf run. Output of runs 6 and 7 of the stand-in harness in the section below: a dry run on a bare box, then a dry run on a box that has the role but not the zone or the forwarders:

What if: Performing the operation "Install" on target "DNS Server role".
Dry run: role not installed, stopping here.

What if: Performing the operation "Create file-backed primary zone" on target "example.local".
What if: Performing the operation "Set to 8.8.8.8, 1.1.1.1" on target "DNS forwarders".
Changes made: 0

The second role check exists because of this. Under -WhatIf the install was skipped, so the role is still missing, and the zone and forwarder cmdlets need the role. On a dry run the script says so and stops with return. On a real run, a role that is still missing after Install-WindowsFeature is a genuine failure, so the script throws. Changes made counts real changes only, so it prints 0 on every dry run.

How each check works

The forwarder comparison ignores order on purpose. The cmdlet has an -EnableReordering option that lets the server reorder forwarders dynamically, so an order-sensitive check could rewrite a correct list on every run. The IPAddress property on the returned object is inferred from the setter, which accepts IPAddress by property name. Confirm it once on a real server with Get-DnsServerForwarder | Format-List.

Proving it is repeatable

The stand-ins below replace the six DnsServer and ServerManager cmdlets with a small in-memory state, so the script's decisions run on any PowerShell 7 host. They work because PowerShell resolves a name to a function you defined in the session before it looks for a cmdlet of the same name, so ./dns-setup.ps1 calls the stand-ins without any change to the script. $global:state is the fake server's memory: whether the role is installed, which zones exist, and which forwarders are set. They exercise the logic only. The real cmdlets run on Windows Server.

# Stand-ins so the script's decision logic runs on any PowerShell 7 host.
$global:state = @{ Installed = $false; Zones = @('.'); Fwd = @('9.9.9.9') }
function Get-WindowsFeature { param($Name) [pscustomobject]@{ Name = $Name; Installed = $global:state.Installed } }
function Install-WindowsFeature { param($Name, [switch]$IncludeManagementTools) $global:state.Installed = $true }
function Get-DnsServerZone { $global:state.Zones | ForEach-Object { [pscustomobject]@{ ZoneName = $_ } } }
function Add-DnsServerPrimaryZone { param($Name, $ZoneFile) $global:state.Zones += $Name }
function Get-DnsServerForwarder { [pscustomobject]@{ IPAddress = @($global:state.Fwd | ForEach-Object { [ipaddress]$_ }) } }
function Set-DnsServerForwarder { param([ipaddress[]]$IPAddress) $global:state.Fwd = @($IPAddress | ForEach-Object { $_.ToString() }) }

'1. first run on a bare box';          ./dns-setup.ps1
'2. second run';                       ./dns-setup.ps1
'3. server reordered the forwarders';  $global:state.Fwd = @('1.1.1.1', '8.8.8.8'); ./dns-setup.ps1
'4. someone added a third forwarder';  $global:state.Fwd += '9.9.9.9'; ./dns-setup.ps1
'5. dry run on a converged box';       ./dns-setup.ps1 -WhatIf
$global:state = @{ Installed = $false; Zones = @('.'); Fwd = @('9.9.9.9') }
'6. dry run on a bare box';            ./dns-setup.ps1 -WhatIf
$global:state.Installed = $true
'7. dry run, role present, no zone, wrong forwarders'; ./dns-setup.ps1 -WhatIf

Output, with the script saved as dns-setup.ps1 beside the harness:

1. first run on a bare box
Changes made: 3
2. second run
Changes made: 0
3. server reordered the forwarders
Changes made: 0
4. someone added a third forwarder
Changes made: 1
5. dry run on a converged box
Changes made: 0
6. dry run on a bare box
What if: Performing the operation "Install" on target "DNS Server role".
Dry run: role not installed, stopping here.
7. dry run, role present, no zone, wrong forwarders
What if: Performing the operation "Create file-backed primary zone" on target "example.local".
What if: Performing the operation "Set to 8.8.8.8, 1.1.1.1" on target "DNS forwarders".
Changes made: 0

Reading runs 1 to 5 against the state each one starts from (runs 6 and 7 are the two dry runs shown in the -WhatIf section above):

The first run makes 3 changes (role, zone, forwarders). The second makes none. A reordered list is not drift. An extra forwarder is drift, so exactly one change brings it back. The dry run on a converged box prints no "What if" line.

Verify on a real server

Get-WindowsFeature -Name DNS | Select-Object Name, Installed
Get-DnsServerZone | Where-Object ZoneName -eq 'example.local'
Get-DnsServerForwarder
Resolve-DnsName -Name example.local -Type SOA -Server 127.0.0.1
Resolve-DnsName -Name www.microsoft.com -Type A -Server 127.0.0.1 -DnsOnly

Expect Installed True, one zone row of type Primary, the two forwarder addresses (in either order), an SOA (start of authority) record for the zone from the local server, and an address for the external name that was resolved through the forwarders. The -DnsOnly switch makes Resolve-DnsName use only the DNS protocol, so it does not fall back to LLMNR or NetBIOS name lookups that could answer without the DNS server. The last line is the end-to-end proof, because it only works if recursion through the forwarders works.

Choices and pitfalls

• Forwarder behaviour. Per the cmdlet documentation the server waits 5 seconds for one forwarder before trying the next, and after exhausting all forwarders it falls back to normal recursion (the server asking other DNS servers, starting from its root hints, a built-in list of the root DNS servers, until it finds the answer) unless -UseRootHint $false is set. The script leaves both at their defaults because the question asks for neither.
• Public forwarders leak internal names. A query for a name the server cannot answer is sent to 8.8.8.8 or 1.1.1.1. That is acceptable for this lab zone, but in an Active Directory environment use conditional forwarders (forwarders used only for queries about a named domain, such as corp.example.com) for internal domains.
• example.local is a poor real-world name. RFC 6762 reserves .local for multicast DNS (mDNS, where a client sends one query to a group address that every device on the local link listens to), and RFC 6762 says a query for a name ending in .local must be sent to the mDNS multicast address 224.0.0.251. It also allows a client to try unicast DNS at the same time and merge the results, so what a client does with a name in your own .local zone can differ from client to client. Prefer a subdomain of a domain you own, such as corp.example.com.
• Active Directory (AD) integrated zones store the zone in a directory partition instead of a file: replace -ZoneFile with -ReplicationScope (for example Forest). That belongs with the Active Directory topics, and the existence check does not change.

Direct answer

Use two Windows Server file-services features together: DFS Namespaces (DFS-N) gives users one path that never changes, and DFS Replication (DFS-R) keeps one copy of the data in each office. DFS-N is a directory of share locations stored in Active Directory: it hands each client a referral, an ordered list of servers, with the server in the client's own AD site first. DFS-R copies changes between the servers, sending only the changed blocks of a file (remote differential compression, RDC) on a schedule that caps the bandwidth. Seed the large first copy by copying the data (or using DFS-R database cloning) before replication starts, because pushing it over the WAN would take weeks.

flowchart LR
  U1[Office A user] -->|\\corp.example.com\Dept| NS[(Domain-based namespace)]
  U2[Office B user] -->|\\corp.example.com\Dept| NS
  NS -->|referral: own site first| FA[fs-a share Dept]
  NS -->|referral: own site first| FB[fs-b share Dept]
  FA <-->|DFS Replication, RDC, throttled schedule| FB

Part 1: one path, nearest copy

Create a domain-based namespace, meaning its configuration lives in Active Directory and several servers can host it, so it survives the loss of one office. Add a folder with one target per office:

New-DfsnRoot -Path '\\corp.example.com\Dept' -TargetPath '\\fs-a\DeptRoot' -Type DomainV2 `
    -EnableSiteCosting $true
New-DfsnFolder -Path '\\corp.example.com\Dept\Files' -TargetPath '\\fs-a\Dept' -EnableTargetFailback $true

Only the fs-a target exists at this point, on purpose. The order of operations matters: if the fs-b target were published now, office B users would be referred to a server with no data yet. The sequence is: namespace with the fs-a target (this part), replication group with fs-a only (Part 2), seed fs-b and join it (Part 3), and only then add the fs-b folder target (the last step of Part 3).

How users reach the nearest copy once both targets exist:

• DFS-N orders the referral by AD site (an Active Directory object that represents a well-connected set of IP subnets, usually one office): the client's own site first, then other targets. This only works if both offices exist in Active Directory Sites and Services with their IP subnets defined, because the client's site is derived from its subnet.
• EnableSiteCosting makes the fallback order follow the site link costs instead of random order, so a failure at one office sends users to the other over the cheaper path. EnableTargetFailback returns clients to their local server when it comes back. Clients cache a root referral for 300 seconds by default and a folder referral for 1800 seconds.
• Users always type \\corp.example.com\Dept\Files, so moving a server only changes a target.

For a folder where two offices often edit the same file, do not give both targets equal rank. DFS-R is multi-master (every member accepts writes and replicates them to the others), so two simultaneous edits of one file end with one version winning. A referral priority class overrides the site ordering: GlobalHigh puts a target first for every client and GlobalLow puts it last. Making fs-a GlobalHigh sends everyone to the primary office and keeps fs-b as a standby. Run these after the fs-b target exists (Part 3, step 5):

Set-DfsnFolderTarget -Path '\\corp.example.com\Dept\Files' -TargetPath '\\fs-a\Dept' -ReferralPriorityClass GlobalHigh
Set-DfsnFolderTarget -Path '\\corp.example.com\Dept\Files' -TargetPath '\\fs-b\Dept' -ReferralPriorityClass GlobalLow

Part 2: keep the data in sync without saturating the link

DFS-R is configured as a replication group with one replicated folder. Build it in two stages: first the group with only fs-a, the server that already holds the data and is the primary member (the one whose files DFS-R treats as authoritative the first time it compares the two sides, so a stale copy on the other server cannot overwrite the real data); fs-b joins after it has been seeded (Part 3).

New-DfsReplicationGroup 'RG-Dept' |
    New-DfsReplicatedFolder -FolderName 'Dept' |
    Add-DfsrMember -ComputerName 'fs-a'
Set-DfsrMembership -GroupName 'RG-Dept' -FolderName 'Dept' -ComputerName 'fs-a' -ContentPath 'D:\Data\Dept' -PrimaryMember $true
Update-DfsrConfigurationFromAD

Set-DfsrMembership always needs the group, the replicated folder and the member computer named together (-GroupName, -FolderName, -ComputerName), because a replicated folder only has a content path and a primary flag once it is tied to one member of one group; later calls shown here that pass a freshly added member down the pipeline get the group and computer names from that member.

Replication is bandwidth-aware in two ways. RDC sends only the changed parts of a file that already exists on the other side. The group schedule caps the rate per 15-minute block. Assume a 10 Mbps WAN: hold replication to 2 Mbps (20 percent of the link) from 08:00 to 18:00, when users share the link, and 8 Mbps (80 percent) the rest of the day. The schedule string has 96 hexadecimal characters (24 hours times 4 blocks of 15 minutes); each character is one 15-minute block and holds a bandwidth code from 0 to F. Microsoft's table for the cmdlet reads: 0 no replication, 1 = 16 Kbps, 2 = 64 Kbps, 3 = 128 Kbps, 4 = 256 Kbps, 5 = 512 Kbps, 6 = 1 Mbps, 7 = 2 Mbps, 8 = 4 Mbps, 9 = 8 Mbps, A = 16 Mbps, B = 32 Mbps, C = 64 Mbps, D = 128 Mbps, E = 256 Mbps, F = full bandwidth. So 7 means 2 Mbps and 9 means 8 Mbps:

$hours = 0..23 | ForEach-Object { if ($_ -ge 8 -and $_ -lt 18) { '7' } else { '9' } }
$bandwidth = -join ($hours | ForEach-Object { $_ * 4 })
Set-DfsrGroupSchedule -GroupName 'RG-Dept' `
    -Day Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday `
    -BandwidthDetail $bandwidth

In PowerShell, multiplying a string by a number repeats it: '7' * 4 is 7777. The script therefore turns each hour into four identical blocks, and joining 24 hours gives 96 characters. The string is 32 nines (hours 0 to 7, 8 hours x 4 blocks), 40 sevens (hours 8 to 17, 10 hours x 4 blocks), then 24 nines (hours 18 to 23, 6 hours x 4 blocks); 32 + 40 + 24 = 96. Once fs-b has joined (Part 3), watch replication health with the backlog, the list of changes the destination has not received yet; the verbose switch prints the count of backlogged files (0 means fs-b has received everything fs-a has sent so far):

Get-DfsrBacklog -GroupName 'RG-Dept' -FolderName 'Dept' `
    -SourceComputerName 'fs-a' -DestinationComputerName 'fs-b' -Verbose

A backlog is latency, not necessarily a fault; alert when it keeps growing across a full day. Two folders on each member need a size limit. The staging folder holds a compressed copy of a file while it is being sent; the ConflictAndDeleted folder keeps files that lost a conflict or were deleted, so they can be restored. Each defaults to 4096 MB. When a folder reaches 90 percent of its quota, DFS-R deletes the oldest files until it falls to 60 percent, so a quota smaller than the largest files forces constant cleanup and re-staging. A larger staging quota keeps staged data longer and improves replication performance. For example, with a 16384 MB staging quota (an illustrative size) cleanup starts at 16384 x 0.9 = 14,745.6 MB and stops at 16384 x 0.6 = 9,830.4 MB:

Set-DfsrMembership -GroupName 'RG-Dept' -FolderName 'Dept' -ComputerName 'fs-a' `
    -StagingPathQuotaInMB 16384 -ConflictAndDeletedQuotaInMB 4096 -Force

Repeat the command for fs-b after it joins in Part 3.

Part 3: seed the initial dataset

Take a 2 TB dataset as the example. The capped schedule moves 10 hours at 2 Mbps plus 14 hours at 8 Mbps per day, which is (10 hours x 2 Mbps + 14 hours x 8 Mbps) = 132 Mbps-hours. Multiply by 3,600 seconds per hour to get megabits: 132 x 3600 = 475,200 Mbit. Divide by 8 bits per byte: 59,400 MB, or 59.4 GB (decimal) per day. 2,000 GB divided by 59.4 GB per day is about 33.7 days, even with the link fully used by replication. Seeding removes that.

1. Start from the group built in Part 2, in which only fs-a is a member, so nothing replicates yet.
2. Copy the data to fs-b preserving permissions, owners and timestamps: the Basic validation level compares size, modified time and a hash of the ACL, so a copy that loses permissions is treated as different and sent again. Use a LAN copy before the server moves, or an external disk shipped to the office:

robocopy D:\Data\Dept \\fs-b\D$\Data\Dept /E /B /COPYALL /R:6 /W:5 /MT:64 /XD DfsrPrivate /TEE /LOG+:preseed.log

When it finishes, robocopy prints a summary table with the rows Dirs, Files and Bytes and the columns Total, Copied, Skipped, Mismatch, FAILED and Extras. Read the FAILED column first: it must be 0 for every row before you go on, and a non-zero count means files (often locked or too-long paths) did not reach fs-b. /B copies in backup mode to read files regardless of their ACLs, /COPYALL keeps data, attributes, timestamps, ACLs, owner and auditing information, /XD DfsrPrivate skips DFS-R's own folder, /MT:64 uses 64 threads (valid range 1 to 128), and /R:6 /W:5 limits retries because robocopy's default is a million retries 30 seconds apart.
3. For a very large dataset, use DFS-R database cloning so fs-b does not have to hash every file again. On fs-a, export the database for the volume (replication on that volume stops while it runs, and the path must be on a local volume), copy the clone files, then import on fs-b:

Export-DfsrClone -Volume 'D:' -Path 'D:\DfsRClone' -Validation Basic
Get-DfsrCloneState
# copy D:\DfsRClone to fs-b, remove D:\System Volume Information\dfsr there if present, then on fs-b:
Import-DfsrClone -Volume 'D:' -Path 'D:\DfsRClone'
Get-DfsrCloneState

Export-DfsrClone does not return until the export finishes, so run Get-DfsrCloneState from a second console. It prints one word: Started DB Export while prerequisites are validated, Processing DB Export while the database is written, and Ready before cloning starts and after it completes. The import side shows Started DB Import and Processing DB Import the same way. Wait for Ready on each server before moving on.

Validation levels trade speed for assurance: None assumes the copy is perfect, Basic compares size, modified time and a hash of the ACL for each file and replicates only differences, Full computes the DFS-R hash for every file. A mismatched file is moved aside to the PreExisting or ConflictAndDeleted folder and replicated again, not silently kept.
4. Add fs-b to the group with the same content path and connect it to fs-a, then refresh the configuration on both servers so each reads the new membership from Active Directory. The first replication cycle then moves only the differences (what changed during the copy), not 2 TB:

Add-DfsrMember -GroupName 'RG-Dept' -ComputerName 'fs-b' |
    Set-DfsrMembership -FolderName 'Dept' -ContentPath 'D:\Data\Dept'
Add-DfsrConnection -GroupName 'RG-Dept' -SourceComputerName 'fs-a' -DestinationComputerName 'fs-b'
Update-DfsrConfigurationFromAD

5. When the backlog from Part 2 reaches 0, publish the second copy to users by adding the fs-b folder target to the namespace. Users in office B are now referred to fs-b first because it sits in their AD site:

New-DfsnFolderTarget -Path '\\corp.example.com\Dept\Files' -TargetPath '\\fs-b\Dept'

Trade-offs and pitfalls

• DFS-R is replication, not backup: a deletion replicates to the other office within minutes. Keep backups at one site and test restores.
• DFS-N and DFS-R are separate features. The namespace chooses where users read and write; replication only moves the data. A namespace with two active targets and replication that is behind will show users different content in each office; the backlog count is the number to watch.
• Domain-based namespace servers must be members or domain controllers in the domain and, unlike a stand-alone namespace, the namespace cannot be a clustered resource.
• The dataset alternative is Azure File Sync, which keeps a full copy in Azure and a cache on each Windows file server; choose it when cloud storage and backup are already part of the plan.
• Do not restore a replicating server from a virtual machine snapshot or saved state: DFS-R fails afterwards and needs special database recovery.

Direct answer

Put people in role groups, never on the folder. Use the AGDLP pattern (Accounts into Global groups, Global groups into Domain Local groups, Domain Local groups get the permission): three Domain Local groups on the file server's domain, one per access level. A Domain Local group can be placed in permission lists only in its own domain, but it can hold members from any trusted domain. A Global group can hold only accounts from its own domain, but can be placed inside groups of other trusted domains. Give the share permission of Full Control to those three groups and let NTFS (the file system's own permissions) draw the real lines: Managers Full Control, Employees Modify, HR Read and execute. A user's effective access is the combination of NTFS entries across every group in their access token, then cut down by the share permissions. To verify, look at the token the user actually logs on with, expand the nested groups in each domain, and check the effective result on the folder. To audit, switch on file system auditing and read the access events.

Design: who gets what

Terms used below. A share permission applies only to people reaching the folder over the network (SMB). An NTFS permission applies to the folder however it is reached. When both apply, the user gets the more restrictive result. An access token is the list of SIDs (security identifiers) for the user and every group they belong to, built at logon.

Domain vocabulary. A domain is one Active Directory unit with its own accounts, groups and domain controllers. A child domain such as eu.corp.example.com sits under a parent such as corp.example.com. A forest is the set of related domains that share one directory structure. A trust is the agreement that lets one domain accept accounts and groups from another, and parent and child domains in a forest trust each other automatically. Every domain has its own group list, which is why a group from one domain reaches a folder in another only by being a member of a group the folder's domain can use.

Each DL group is a Domain Local group, which can hold accounts and Global groups from any trusted domain, and can be used for permissions only inside its own domain. Each Global group (for example GG_Managers_CORP and GG_Managers_EU, one per domain) holds that domain's users. That is what makes cross-domain users work: a user in the eu.corp child domain sits in the EU Global group, and that Global group sits inside the DL group in the file server's domain.

Why share Full Control rather than mirroring NTFS: a share permission of Change cannot be raised by NTFS. Managers would have Full Control on the folder yet be unable to change permissions over the network. Keeping the share layer at Full Control for exactly the three groups leaves one place (NTFS) to reason about.

Build it

$root = 'D:\Shares\Dept'
New-Item -ItemType Directory -Path $root -Force | Out-Null

# Share layer: only the three DL groups, Full Control, hide what a user cannot open
New-SmbShare -Name 'Dept' -Path $root -FolderEnumerationMode AccessBased `
    -FullAccess 'CORP\DL_Dept_Managers_FC', 'CORP\DL_Dept_Employees_M', 'CORP\DL_Dept_HR_R'

# NTFS layer: stop inheriting, drop inherited entries, add exactly five entries
$acl = Get-Acl -Path $root
$acl.SetAccessRuleProtection($true, $false)
$rules = @(
    @('NT AUTHORITY\SYSTEM',          'FullControl'),
    @('BUILTIN\Administrators',       'FullControl'),
    @('CORP\DL_Dept_Managers_FC',     'FullControl'),
    @('CORP\DL_Dept_Employees_M',     'Modify'),
    @('CORP\DL_Dept_HR_R',            'ReadAndExecute')
)
foreach ($r in $rules) {
    $ace = [System.Security.AccessControl.FileSystemAccessRule]::new(
        $r[0], $r[1], 'ContainerInherit,ObjectInherit', 'None', 'Allow')
    $acl.AddAccessRule($ace)
}
Set-Acl -Path $root -AclObject $acl

-FolderEnumerationMode AccessBased turns on access-based enumeration (ABE): users see only the files and folders they can open. It is off by default. The ACL has five entries (SYSTEM, Administrators, and the three DL groups), each applied to the folder, its subfolders and its files.

Reading the script line by line:

• New-Item ... -Force | Out-Null creates the folder (and any missing parents) and hides the output.
• New-SmbShare publishes the folder as \server\Dept. -FullAccess lists the accounts given the Full share permission. Any account not listed gets no share access.
• Get-Acl reads the folder's current permission list into an object in memory. Nothing changes on disk until Set-Acl.
• SetAccessRuleProtection($true, $false) takes two switches. The first, $true, protects the folder from inheritance, so changes on the parent folder (D:\Shares or D:) no longer flow down. The second, $false, means do not keep the entries that were already inherited, so they are removed. Use $true, $true instead to protect the folder but keep a copy of the inherited entries as ordinary entries.
• The $rules list pairs each account with a right name from the .NET FileSystemRights set. ReadAndExecute is the "Read and execute" right.
• FileSystemAccessRule::new(...) takes five arguments in this order: account, rights, inheritance flags, propagation flags, allow or deny. 'ContainerInherit,ObjectInherit' makes the entry apply to subfolders (containers) and files (objects) below. 'None' as the propagation flag means the entry applies to the folder itself as well, not only to its children, and does not stop after one level. 'Allow' makes it an Allow entry.
• AddAccessRule adds each entry to the in-memory list, and Set-Acl writes the finished list to the folder in one step.

Worked example: effective access for five users

Effective access is (union of NTFS rights from all the user's groups) intersected with (union of share rights from all the user's groups). With no Deny entries, adding a group can only add rights.

Reading the table: for amy, the NTFS column is the best right any of her groups gives (Full Control), the share column is the best share right (Full), and the effective column is the smaller of the two. Raj is the same calculation with Modify, because his token holds the Employees group through his EU Global group.

Omar is the trap. He is in both groups, so HR's "read-only" does not hold for him: the union gives Modify. Do not fix this with a Deny entry on the HR group, because Deny beats Allow and would also lock out a manager who happens to be in HR. Fix it with membership control: Employees and HR are mutually exclusive roles, and a periodic report flags anyone in both.

If someone had set the share permission to Change for everyone, amy's effective result would drop to read, write and delete: the share layer cuts off change-permissions even though NTFS grants it.

Verify the effective access of a user with nested, cross-domain groups

1. Read the token, not the directory. Ask the user to run whoami /groups in their own session (or run it from a test logon). It lists the SIDs that are actually in that logon session's token, including nested group memberships, so it shows what Windows really sees rather than what the directory says now. A Domain Local group can be used only inside its own domain, so confirm the Domain Local row in a session on the file server (for example a test logon there) if it is missing on the workstation. Group changes reach the token only at the next logon, so "I was just added" needs a sign-out and sign-in. Illustrative output for raj in a session on the file server (the SIDs and some rows are made up for the example):

GROUP INFORMATION
-----------------

Group Name                              Type             SID                                Attributes
======================================= ================ ================================== ==================================================
Everyone                                Well-known group S-1-1-0                            Mandatory group, Enabled by default, Enabled group
EU\Domain Users                         Group            S-1-5-21-111-222-333-513           Mandatory group, Enabled by default, Enabled group
EU\GG_Employees_EU                      Group            S-1-5-21-111-222-333-1104          Mandatory group, Enabled by default, Enabled group
CORP\DL_Dept_Employees_M                Alias            S-1-5-21-444-555-666-2201          Mandatory group, Enabled by default, Enabled group

Read it as follows. Group Name is the group, with its domain prefix. Type shows Group for a Global or Universal group and Alias for a Domain Local group. SID is the identifier the access check compares with the folder's entries, and the middle numbers (111-222-333 versus 444-555-666) identify the domain that issued it, so you can tell which domain each group lives in. Attributes show whether the entry is active. Here the row CORP\DL_Dept_Employees_M is present, so raj gets Modify. If that row were missing, the nesting, the logon time, or reading the token somewhere other than the file server's domain would be the first things to check.
2. Expand the nesting per domain to see why a group is there. A group's membership list lives in the domain that owns the group, and the nesting search below cannot follow a link across a domain boundary. So run it in two passes: first in the user's own domain, then ask the file server's domain which of its groups hold the user or one of those groups. A distinguished name (DN) is the full directory path of an object, such as CN=raj,OU=Staff,DC=eu,DC=corp,DC=example,DC=com; the search needs it because the membership lists store members by DN.

$userDomain     = 'eu.corp.example.com'
$resourceDomain = 'corp.example.com'
$user = Get-ADUser -Identity 'raj' -Server $userDomain

# Pass 1: every group in the user's own domain whose member list holds the user, nesting included
$filter = "(member:1.2.840.113556.1.4.1941:=$($user.DistinguishedName))"
$homeGroups = @(Get-ADGroup -LDAPFilter $filter -Server $userDomain)
$homeGroups | Select-Object Name, GroupScope

# Pass 2: groups in the file server's domain that hold the user or one of those groups
foreach ($member in @($user) + $homeGroups) {
    Get-ADPrincipalGroupMembership -Identity $member -ResourceContextServer $resourceDomain |
        Select-Object @{n='Via'; e={$member.Name}}, Name, GroupScope
}

The OID 1.2.840.113556.1.4.1941 is the in-chain matching rule, which walks nested membership in one query. On large directories a search with many groups can be processor heavy. The filter (member:1.2.840.113556.1.4.1941:=<DN>) reads as: find groups whose member list contains this DN, directly or through groups inside groups.

What the script does. Pass 1 builds that filter from raj's DN and lists every group in eu.corp whose member list holds him, however deeply nested (GG_Employees_EU and so on). His primary group (by default Domain Users) is recorded on his own account in the primaryGroupID attribute rather than in a member list, so do not expect a member-list search to return it. Pass 2 loops over raj himself and each of those groups and, with Get-ADPrincipalGroupMembership -ResourceContextServer, asks the file server's domain which of its groups contain that principal. That is where a Domain Local group such as DL_Dept_Employees_M turns up. Learn notes that Get-ADPrincipalGroupMembership needs a global catalog and that -ResourceContextServer is the way to ask a domain other than the account's own for the groups that reside there. Illustrative output of pass 2:

Via             Name                GroupScope
---             ----                ----------
GG_Employees_EU DL_Dept_Employees_M DomainLocal

Read it as: raj reaches the Employees permission because his EU Global group GG_Employees_EU is a member of the Domain Local group DL_Dept_Employees_M. If the Via column shows raj instead, he was added to that group directly. An empty result means no group in the file server's domain holds him, which explains a "no access" ticket.

3. Compute the result on the folder. In File Explorer open Properties, Security, Advanced, Effective Access, choose the user, and read the result: the tab lists each right (Full control, Modify and so on) with a tick or a cross, and on newer systems names the group entry that grants or denies it. Evaluate share permissions separately with Get-SmbShareAccess -Name Dept.
4. List the ACL as a text record for the ticket: icacls D:\Shares\Dept.

Audit

Turn on the File System subcategory and add an auditing entry (a SACL) on the folder for the groups and rights you care about, then read the events:

auditpol /set /subcategory:"File System" /success:enable /failure:enable

Event 4663 ("An attempt was made to access an object") records the account, the object name, the access rights used and the process, and it is generated only when the object's SACL has a matching entry. Watch for write, delete, change-permissions and take-ownership rights against the folder.

Trade-offs and pitfalls

• Do not assign users to the NTFS ACL directly, and do not build chains of nested groups beyond the Accounts, Global, Domain Local pattern (a Domain Local group can contain other Domain Local groups only from its own domain): both make the effective result hard to explain in a ticket.
• Modify includes delete. If employees must edit but not delete, use a custom right set instead of Modify.
• Share permissions apply only to network access. Someone signed in at the console or over Remote Desktop is judged by NTFS alone, so NTFS must be correct even if the share looks tight.
• Disabling inheritance at the top and granting named groups is deliberate: leaving the Users group on the inherited ACL is how department data ends up readable by everyone.

Direct answer

A role is the main job a server performs for other computers (DNS Server, DHCP Server, Web Server (IIS), Active Directory Domain Services). A role service is an optional piece inside a role (for example the Common HTTP Features inside Web Server, or Remote Desktop Licensing inside Remote Desktop Services). A feature is a supporting capability that is not a server's main job: it extends the operating system or the tooling (Failover Clustering, BitLocker Drive Encryption, Windows Server Backup, SNMP Service, Telnet Client, and the Remote Server Administration Tools, or RSAT). You install only a feature when the machine should gain a capability or admin tool without becoming a server for that function, such as adding the Active Directory PowerShell module to a management server so you can administer AD without installing the AD DS role.

How the three relate

The Server Manager wizard shows Server Roles and Features as separate pages, and Install-WindowsFeature installs all three kinds (roles, role services and features) by internal name. Roles often pull in required features automatically as dependencies.

Commands

# What is installed, and what could be installed
Get-WindowsFeature | Where-Object Installed
Get-WindowsFeature -Name Web-Server, RSAT-AD-PowerShell

# Preview first, then install a role with all its role services and the management tools
Install-WindowsFeature -Name Web-Server -IncludeAllSubFeature -IncludeManagementTools -WhatIf
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

# Install only a feature: the AD PowerShell module on a management server (no AD DS role)
Install-WindowsFeature -Name RSAT-AD-PowerShell

Install-WindowsFeature does not install the management tools unless you add -IncludeManagementTools, so a role can end up installed with no console to manage it. -WhatIf shows what would be installed without changing anything. Verify afterwards with Get-WindowsFeature -Name <name> and look at the Installed and InstallState values. For example, Get-WindowsFeature -Name Web-Server, RSAT-AD-PowerShell | Select-Object Name, Installed, InstallState prints a table like this (illustrative values):

Name               Installed InstallState
----               --------- ------------
Web-Server              True Installed
RSAT-AD-PowerShell     False Available

Installed is a simple True or False. InstallState is the fuller status: Installed, Available (not installed, and the files are on the machine), or Removed (the files were deleted from the machine, so an install needs an outside source). Here the web server role is present and the AD PowerShell feature is not yet installed.

When I install only a feature

• Admin workstation or jump server (a hardened administration machine you connect through to manage other servers): RSAT-AD-PowerShell and the other RSAT tools, so I can manage AD, DNS or DHCP remotely without making that machine a domain controller or DNS server.
• High availability: Failover-Clustering on two or more file or SQL servers to cluster them; no new role is involved.
• Recoverability: Windows-Server-Backup on a member server that has no backup agent.
• Test connectivity from a locked-down server: the Telnet Client feature gives a quick TCP port check, though Test-NetConnection -Port does the same without installing anything.

Trade-offs and pitfalls

• Install the minimum. Every role adds services, open ports and patches, which enlarges the attack surface (the total set of running services, open ports and code an attacker could try to abuse). A feature-only install is usually a smaller commitment than a role.
• Server Core (the install option with no desktop experience) supports a subset of the roles and features, installed by command or remote tools; manage it remotely with RSAT rather than adding a GUI.
• Plan for retirement. The Windows Server Update Services role (UpdateServices) is still installable, but Microsoft states WSUS is no longer actively developed (existing capabilities and content continue to work), so choose it for new builds only with a migration plan.
• Do not confuse a feature with a Windows capability or an application. Some tools (for example WMIC in Windows Server 2025) are Features on Demand (optional Windows components that are not stored on the machine until you add them) added with DISM (Deployment Image Servicing and Management, a command-line tool that adds and removes Windows components), a different mechanism.