Windows Server

---
name: windows-server
description: "Microsoft Windows Server across all versions (2016-2025): server roles/features, PowerShell administration, Active Directory, storage (NTFS/ReFS/Storage Spaces), networking (SMB/NIC Teaming/SET), security hardening, performance monitoring, and diagnostics. Use when: \"Windows Server\", \"Server Core\", \"PowerShell remoting\", \"Active Directory\", \"Group Policy\", \"Storage Spaces Direct\", \"S2D\", \"SMB\", \"NIC Teaming\", \"NTFS\", \"ReFS\", \"WSUS\", \"Windows Admin Center\", \"WAC\", \"Credential Guard\", \"event log\", \"perfmon\", \"WinRM\". Do NOT use for Hyper-V virtualization internals — use the `hyper-v` skill. Do NOT use for Failover Cluster quorum/CSV mechanics — use the `failover-clustering` skill."
license: MIT
---

# Windows Server

This skill covers Microsoft Windows Server across all supported versions (2016 through 2025). It provides deep knowledge of:

- Server roles, features, and the Install-WindowsFeature model
- PowerShell administration and remoting patterns
- Active Directory Domain Services, Group Policy, and Kerberos authentication
- Hyper-V virtualization, containers, and hyperconverged infrastructure
- Security model (VBS, Credential Guard, HVCI, LSASS protection, TLS hardening)
- Storage subsystem (NTFS, ReFS, Storage Spaces, Storage Spaces Direct)
- Networking stack (SMB 3.x, NIC Teaming, SET, DNS, WFP/Windows Firewall)
- Performance monitoring (Get-Counter, Data Collector Sets, Event Logs)
- Backup, recovery, and disaster recovery planning

When a question is version-specific, read the relevant file under `references/versions/`. When the version is unknown, provide general guidance and note where behavior differs across versions. Deep dives on Failover Clustering and Hyper-V live in their own sibling skills: `failover-clustering`, `hyper-v`.

## How to Approach Tasks

Route by request type: **troubleshooting** → `references/diagnostics.md`; **optimization** → `references/best-practices.md`; **architecture** → `references/architecture.md`; **edition selection** → `references/editions.md`; **administration** → the guidance below.

**Identify the Windows Server version first** — feature availability, security defaults, and the container runtime all shift by version. Apply Windows Server-specific reasoning, not generic OS advice. Validate with cmdlets, event log checks, and performance counters.

## Core Expertise

### Roles and Features Model

Windows Server uses a declarative roles-and-features model managed through `Install-WindowsFeature` (Server Manager) or `Enable-WindowsOptionalFeature` (DISM). Key principles:

- Install only the roles required for the server's function -- every role expands the attack surface
- Use `Get-WindowsFeature` to audit installed roles; compare against a known-good baseline
- Server Core installations lack the Desktop Experience feature, reducing attack surface by ~40%
- Some features are mutually exclusive (e.g., Hyper-V role and Device Guard on the same host require careful configuration)

```powershell
# List all installed roles and features
Get-WindowsFeature | Where-Object Installed | Select-Object Name, InstallState

# Install a role with management tools
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# Remove a role cleanly (includes binaries with -Remove)
Uninstall-WindowsFeature -Name Web-Server -Remove
```

### PowerShell Administration Patterns

PowerShell is the primary administration interface. Prefer CIM over WMI, structured commands over ad-hoc parsing:

- **Remote management:** Use `Enter-PSSession` for interactive sessions, `Invoke-Command` for batch execution across multiple servers
- **CIM over WMI:** Use `Get-CimInstance` instead of `Get-WmiObject` -- CIM uses WS-Man by default, supports DCOM fallback, and is the supported path forward
- **Desired State Configuration (DSC):** Declare server configuration as code for repeatable deployments
- **Just Enough Administration (JEA):** Create constrained PowerShell endpoints that grant specific administrative capabilities without full administrator rights

```powershell
# Remote command execution across multiple servers
Invoke-Command -ComputerName srv1,srv2,srv3 -ScriptBlock {
    Get-Service -Name WinRM | Select-Object Name, Status
}

# CIM-based system info (preferred over Get-WmiObject)
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, LastBootUpTime, FreePhysicalMemory
```

### Server Core vs Desktop Experience

Choose Server Core unless a specific role or application requires the GUI shell:

| Factor | Server Core | Desktop Experience |
|---|---|---|
| Attack surface | ~40% smaller | Full |
| Patch frequency | Fewer monthly patches | All patches |
| Disk footprint | ~4 GB less | Full |
| Management | PowerShell, WAC, RSAT, sconfig | GUI consoles locally |
| Best for | AD DS, DNS, DHCP, Hyper-V, File Server, IIS | RD Session Host, WDS, some third-party apps |

Manage Server Core remotely via Windows Admin Center (WAC), RSAT tools, or PowerShell remoting. Use `sconfig` for initial interactive setup (hostname, domain join, network, Windows Update).

### Performance Monitoring

The primary entry point for performance investigation is the performance counter subsystem:

**CPU:**
- `\Processor(_Total)\% Processor Time` -- Sustained >70% = warning, >90% = critical
- `\System\Processor Queue Length` -- >2 per logical CPU = CPU bottleneck

**Memory:**
- `\Memory\Available MBytes` -- <10% of total RAM = warning
- `\Memory\Pages/sec` -- >500 = heavy paging to disk

**Disk:**
- `\PhysicalDisk(*)\Avg. Disk sec/Read` -- >20ms (HDD) or >5ms (SSD) = latency concern
- `\PhysicalDisk(*)\Disk Queue Length` -- >4 sustained = storage bottleneck

**Network:**
- `\Network Interface(*)\Bytes Total/sec` -- >70% of link speed = saturation
- `\Network Interface(*)\Output Queue Length` -- >2 = NIC queuing

```powershell
# Quick performance snapshot
Get-Counter '\Processor(_Total)\% Processor Time',
            '\Memory\Available MBytes',
            '\PhysicalDisk(_Total)\Avg. Disk sec/Read' -SampleInterval 5 -MaxSamples 6

# Create a 24-hour baseline Data Collector Set
logman create counter ServerBaseline `
    -c "\Processor(*)\% Processor Time" "\Memory\Available MBytes" `
       "\PhysicalDisk(*)\Avg. Disk sec/Read" "\PhysicalDisk(*)\Disk Queue Length" `
       "\Network Interface(*)\Bytes Total/sec" `
    -si 00:00:15 -f csv -o C:\PerfLogs\Baseline -rf 24:00:00
logman start ServerBaseline
```

### Security Model Overview

Windows Server uses a layered security model combining authentication, authorization, and hardware-backed isolation:

**Authentication:**
- Kerberos v5 is the default for domain-joined machines (TGT + service tickets)
- NTLM is the fallback -- NTLMv1 is blocked by default in Server 2025; audit and eliminate NTLMv2 where possible
- LSASS (`lsass.exe`) hosts all authentication packages; protect it with PPL and Credential Guard

**Authorization:**
- Security Reference Monitor (SRM) checks access tokens against object DACLs
- Every process carries an access token with user SID, group SIDs, privileges, and integrity level
- Apply principle of least privilege -- use Group Managed Service Accounts (gMSA) or Delegated MSA (dMSA, 2025) for services

**Virtualization-Based Security (VBS):**
- Uses Hyper-V hypervisor to isolate security-critical processes in Virtual Secure Mode (VSM)
- Credential Guard: moves NTLM hashes and Kerberos TGTs into `LSAIso.exe` inside VSM
- HVCI: validates all kernel-mode code before execution, preventing unsigned driver loading
- Requires: UEFI Secure Boot, TPM 2.0, 64-bit CPU with SLAT

```powershell
# Check VBS and Credential Guard status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesRunning,
                  SecurityServicesConfigured
# VBS Status: 0=Off, 1=Configured, 2=Running
# Services: 1=Credential Guard, 2=HVCI, 4=System Guard Secure Launch
```

### Storage Overview

**NTFS vs ReFS:**

| Feature | NTFS | ReFS |
|---|---|---|
| Boot volume | Yes | No |
| Max file size | 256 TB | 35 PB |
| Integrity checksums | No | Yes (automatic) |
| Self-healing | chkdsk (offline) | Online, automatic |
| Hyper-V VHDX | Supported | Preferred (block cloning) |
| S2D volumes | Supported | Recommended |
| Deduplication | Yes | Yes (2019+) |

Use ReFS for Hyper-V storage, S2D volumes, and data integrity workloads. Use NTFS for boot volumes, application volumes, and environments requiring specific NTFS features (EFS, quotas, ODX).

**Storage Spaces** provides software-defined storage with resiliency types: Simple (striped), Mirror (2-way/3-way), and Parity (RAID-5/6-like). **Storage Spaces Direct (S2D)** extends this to hyperconverged clusters using direct-attached NVMe/SSD/HDD across nodes. S2D requires Datacenter edition.

```powershell
# Check physical disk health
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, Size, HealthStatus, BusType

# Check volume status and free space
Get-Volume | Select-Object DriveLetter, FileSystem, Size, SizeRemaining, HealthStatus
```

### Networking Overview

**SMB 3.x** is the primary file-sharing protocol with key features:
- SMB Multichannel: uses multiple NICs or RSS queues simultaneously
- SMB Direct (RDMA): zero-copy transfers over iWARP/RoCE/InfiniBand NICs
- SMB Encryption: AES-128 (2012+) or AES-256 (2022+) per-share or per-session
- SMB over QUIC: tunnels SMB over UDP/443 with TLS 1.3 (Azure Edition in 2022, all editions in 2025)
- SMB Compression: LZ4/ZSTD in-transit compression (2022+)

**NIC Teaming:**
- LBFO (Load Balancing and Failover): traditional NIC teaming via `Set-NetLbfoTeam` -- incompatible with RDMA
- SET (Switch Embedded Teaming): integrates teaming into the Hyper-V virtual switch -- preserves RDMA capability, required for converged networking

```powershell
# Check SMB configuration
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol,
    RequireSecuritySignature, EncryptData

# Disable SMBv1 (mandatory security hardening)
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
```

### Common Pitfalls

**1. Running with Desktop Experience unnecessarily**
Desktop Experience adds hundreds of components, each a potential vulnerability. Unless the server runs RD Session Host or a GUI-dependent application, use Server Core and manage remotely via WAC or PowerShell.

**2. Leaving SMBv1 enabled**
SMBv1 is the attack vector for EternalBlue/WannaCry. Disable it on every server: `Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force`. Verify with `Get-SmbServerConfiguration | Select EnableSMB1Protocol`.

**3. Ignoring TLS hardening**
Disable TLS 1.0 and 1.1 on all servers. Server 2022+ disables them by default, but 2016 and 2019 require manual configuration via Schannel registry keys. Use the IISCrypto tool or deploy via Group Policy.

**4. Not sizing Event Logs**
Default log sizes are too small for production. Security log at 196 MB minimum, System and Application at 32 MB minimum. Small logs lose critical forensic data during incidents.

**5. Skipping Windows Server Backup or VSS configuration**
Shadow copies and system state backups are the fastest recovery path. Schedule daily system state backups for domain controllers. Configure VSS shadow storage at 10-15% of volume size.

**6. Using local admin for services**
Services running as LocalSystem have unrestricted access. Use gMSA (2012+) or dMSA (2025) for automatic password management and least-privilege operation.

**7. No baseline performance data**
Without a baseline, you cannot determine if current performance is abnormal. Create a 24-hour Data Collector Set capturing CPU, memory, disk, and network counters within the first week of deployment.

**8. Over-relying on NTLM instead of Kerberos**
NTLM is weaker and slower than Kerberos. Audit NTLM usage with `auditpol /set /subcategory:"NTLM" /success:enable /failure:enable` and migrate applications to Kerberos authentication.

**9. Ignoring driver and firmware updates**
Third-party drivers are the leading cause of BSODs. Keep storage controller, NIC, and GPU drivers current. Verify HVCI compatibility before enabling VBS.

**10. Not testing patch rollbacks**
Always test cumulative updates in a pilot ring before production deployment. Maintain a documented rollback procedure using `wusa /uninstall /kb:XXXXXXX` or DISM.

## Version-Specific Guidance

| Version | Reference | What's version-specific |
|---|---|---|
| 2016 | `references/versions/2016.md` | Nano Server, first container support, Shielded VMs, S2D, Storage Replica, Credential Guard, JEA |
| 2019 | `references/versions/2019.md` | Windows Admin Center, System Insights, Storage Migration Service, OpenSSH, Kubernetes nodes |
| 2022 | `references/versions/2022.md` | Secured-core server, TLS 1.3 default, SMB compression/QUIC (Azure Edition), Hotpatch (Azure Edition), nested virt on AMD |
| 2025 | `references/versions/2025.md` | Native NVMe, Hotpatch all editions, SMB over QUIC all editions, DTrace, dMSA, GPU-P, AD 32KB pages |

## Reference Files

Load these when you need deep knowledge for a specific area:

- `references/architecture.md` -- NT kernel internals, boot process, registry, storage stack, networking stack, security architecture. Read for "how does X work" questions.
- `references/diagnostics.md` -- Event log analysis, performance counters, Get-Counter, WinRM, packet capture, BSOD analysis, DTrace. Read when troubleshooting performance or errors.
- `references/best-practices.md` -- CIS/STIG hardening, Group Policy design, patching strategy, backup procedures, monitoring setup. Read for design and operations questions.
- `references/editions.md` -- Standard vs Datacenter vs Azure Edition feature gates, hardware limits, licensing model, upgrade paths. Read for edition selection and licensing questions.