
Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Deploying a new Microsoft operating system requires more than clicking through an installer; it demands a deliberate approach to security baselines and automation. Windows Server 2022: Getting Started correctly means establishing a Secured-core foundation, enforcing TLS 1.3 by default, and configuring remote management before the first workload lands. This guide skips the marketing overview and focuses on the engineering steps required to build a compliant, audit-ready platform that integrates safely with modern hybrid infrastructure.
How do you perform a clean Windows Server 2022 installation?
A common mistake during Windows Server 2022: Getting Started is selecting the wrong edition or skipping the Desktop Experience decision. For most production servers, especially those managed remotely or serving as backend infrastructure, choose Server Core. It reduces the attack surface by removing the GUI stack, decreases patch footprint, and reboots faster. Only select Desktop Experience if you have legacy applications requiring local GUI interaction or if your team lacks sufficient PowerShell proficiency for headless management.
Critical post-installation patching
Never trust the base ISO. Even fresh media from the Volume Licensing Service Center (VLSC) can be months out of date. Your very first task after installation is applying the latest Cumulative Update (CU). In my experience managing fleets across Nepal and global regions, skipping this step leads to immediate compatibility issues with newer Azure Arc agents and monitoring tools. Use sconfig in Server Core or Windows Update in Desktop Experience to pull the latest security rollup before joining a domain or installing roles.
- Edition Selection: Standard vs. Datacenter depends on virtualization density. Datacenter allows unlimited OSEs; Standard permits two.
- Nano Server: Note that Nano Server is no longer available as a host OS in 2022; it exists only as a container base image.
- Driver Injection: If deploying on bare metal, integrate storage and network drivers into the install.wim using DISM before booting to avoid "no disk found" errors.
What are the essential security hardening steps for Windows Server 2022?
Security in Windows Server 2022 shifts left. Unlike previous versions where hardening was entirely post-deploy, 2022 introduces hardware-rooted trust as a prerequisite for many features. When guiding teams through security hardening best practices, I emphasize that Windows now requires similar firmware-level attention to what Linux admins have done with Secure Boot for years.
Enabling Secured-core Server
Secured-core is not a toggle in Server Manager; it is a combination of hardware capabilities and OS configurations. You must verify three pillars:
- TPM 2.0: Required for BitLocker, Credential Guard, and System Guard. Verify presence with
Get-Tpmin PowerShell. - Secure Boot: Must be enabled in UEFI. Prevents unsigned bootloaders and rootkits from loading before the OS kernel.
- System Guard Secure Launch: Uses virtualization-based security (VBS) to validate early boot code. Enable via Group Policy or Intune under Computer Configuration > Administrative Templates > System > Device Guard.
If you are running this on older hardware without TPM 2.0, you cannot achieve true Secured-core status. In such cases, document the exception formally for audits like SOC 2 or ISO 27001, and plan a hardware refresh. Do not attempt software-only workarounds for Credential Guard; they provide negligible protection against modern credential theft attacks.
TLS 1.3 enforcement
Windows Server 2022 supports TLS 1.3 natively, but it does not disable older protocols automatically. Legacy SMBv1, NTLMv1, and TLS 1.0/1.1 remain active unless explicitly disabled. Run the following PowerShell to enforce modern cryptography standards:
# Disable TLS 1.0 and 1.1 client/server
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'Enabled' -Value 0 -Type DWord
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'DisabledByDefault' -Value 1 -Type DWord
# Repeat for TLS 1.1, then enable TLS 1.3 explicitly if needed for legacy apps
# TLS 1.3 is enabled by default in 2022 but verify cipher suite order
Enable-TlsCipherSuite -Name 'TLS_AES_256_GCM_SHA384' -Position 0 Always test TLS changes in staging first. Some older backup agents and monitoring probes still rely on TLS 1.2 at minimum. Breaking connectivity to your monitoring infrastructure because of aggressive cipher pruning is a rite of passage you want to avoid in production.
How do you configure remote management and automation?
In 2026, logging into RDP to manage servers is an anti-pattern. Effective Windows Server 2022: Getting Started workflows rely entirely on PowerShell Remoting (WinRM) and declarative configuration. Treat Windows servers like immutable infrastructure wherever possible, similar to how you would approach PowerShell automation patterns in mature DevOps environments.
Configuring WinRM over HTTPS
Default WinRM uses HTTP on port 5985, which transmits metadata unencrypted. Always configure HTTPS listeners with valid certificates, especially for servers accessible outside the internal VLAN. Generate a certificate with the server's FQDN in the Subject Alternative Name (SAN), then bind it:
# Create HTTPS listener with specific certificate thumbprint
$thumb = (Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.Subject -match 'server.corp.local' }).Thumbprint
New-WSManInstance winrm/config/Listener `
-SelectorSet @{Address='*'; Transport='HTTPS'} `
-ValueSet @{CertificateThumbprint=$thumb}
# Remove default HTTP listener
Remove-WSManInstance winrm/config/Listener `
-SelectorSet @{Address='*'; Transport='HTTP'} For fleet-wide consistency, push this configuration via Group Policy or DSC rather than scripting per-node. If you use Azure Arc, the Connected Machine agent handles its own secure channel, but native WinRM remains essential for on-prem orchestration tools like Ansible or Jenkins.
Desired State Configuration (DSC) basics
DSC ensures your server stays compliant even after manual drift. A simple DSC resource to enforce TLS settings and disable unnecessary services looks like this:
Configuration HardenedServer2022 {
Import-DscResource -ModuleName PSDesiredStateConfiguration
Node localhost {
Registry DisableSMBv1 {
Key = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters'
ValueName = 'SMB1'
ValueType = 'DWord'
ValueData = '0'
Ensure = 'Present'
}
Service DisablePrintSpooler {
Name = 'Spooler'
StartupType = 'Disabled'
State = 'Stopped'
}
}
} Compile this to MOF files and apply via Start-DscConfiguration. Store configurations in Git alongside your infrastructure code. This practice aligns Windows management with the same version-controlled, peer-reviewed workflows used for Kubernetes manifests and Terraform modules.
When should you choose Server Core vs Desktop Experience?
This decision impacts long-term maintenance overhead more than almost any other choice during Windows Server 2022: Getting Started. The table below reflects real-world trade-offs observed across dozens of production deployments.
| Criteria | Server Core | Desktop Experience |
|---|---|---|
| Attack Surface | Minimal (~400MB less code) | Full GUI stack exposed |
| Patch Reboot Frequency | Fewer updates, faster reboots | Monthly GUI-related patches |
| Disk Footprint | ~6 GB base | ~10+ GB base |
| Management Skill Required | PowerShell / CLI mandatory | GUI fallback available |
| Legacy App Compatibility | Limited (no GUI dependencies) | Full compatibility |
| RDP Usage | Discouraged / Rare | Common but risky |
| Best For | DCs, DNS, IIS, Containers | RDS, Legacy LOB Apps |
My recommendation for 2026: Default to Server Core for all new infrastructure roles. Reserve Desktop Experience exclusively for Remote Desktop Session Hosts or applications that vendor documentation explicitly states require a GUI. The operational discipline gained from Core outweighs the initial learning curve, especially when combined with Windows Admin Center for visual management without installing GUI components locally.
Next Steps After Windows Server 2022: Getting Started
Completing the initial setup is just the beginning. True operational maturity comes from integrating this server into your broader observability and automation ecosystem. Connect it to your centralized logging pipeline, enroll it in configuration management, and validate that backups complete successfully before declaring it production-ready. If you need assistance designing a compliant Windows infrastructure or auditing your existing environment against SOC 2 or ISO 27001 controls, reach out to discuss your specific requirements. Proper foundations prevent costly rework later.