8.4 Windows Server Container Hosts, Isolation Models & Images

Windows Server Container Hosts, Isolation Models & Images

Containerization packages applications and their runtime dependencies into lightweight, portable, and immutable execution units. In Windows Server environments, containerization enables legacy .NET Framework applications, modern .NET cloud-native microservices, and enterprise web workloads to achieve high density, automated CI/CD lifecycle pipelines, and instant scaling.

This section covers preparing Windows Server as a container host and the isolation models and base images that decision depends on. Running and lifecycle-managing container instances and Linux containers via WSL are covered in section 8.5; container networking and Azure Kubernetes Service (AKS) enabled by Azure Arc are covered in section 8.6; building, tagging, and distributing images through a registry is covered in section 8.7.

1. Windows Server Container Isolation Models

Windows Server provides two distinct container isolation technologies to balance density against multi-tenant security boundaries:

+-----------------------------------------------------------------------------------------+
|                   WINDOWS SERVER CONTAINER ISOLATION MODELS                             |
|                                                                                         |
|  [PROCESS ISOLATION]                               [HYPER-V ISOLATION]                  |
|  +-------------------+  +-------------------+      +-------------------+  +-------------------+|
|  | Container App A   |  | Container App B   |      | Container App A   |  | Container App B   ||
|  | User Mode (DLLs)  |  | User Mode (DLLs)  |      | User Mode (DLLs)  |  | User Mode (DLLs)  ||
|  +-------------------+  +-------------------+      +-------------------+  +-------------------+|
|  | Shared Host Kernel Engine & Subsystems   |      | Guest Kernel (VM) |  | Guest Kernel (VM) ||
|  | (Namespaces, Job Objects, File System)   |      +-------------------+  +-------------------+|
|  +------------------------------------------+      | Lightweight Hyper-V Utility Partition   ||
|  | Windows Server Physical / Virtual Host   |      +------------------------------------------+|
|  | Operating System Kernel                  |      | Windows Server Host Kernel / Hyper-V     ||
|  +------------------------------------------+      +------------------------------------------+|
+-----------------------------------------------------------------------------------------+

Detailed Comparison:

+-----------------------------------------------------------------------------------------+
|                    PROCESS ISOLATION VS HYPER-V ISOLATION                               |
|                                                                                         |
|   DIMENSION              PROCESS ISOLATION              HYPER-V ISOLATION               |
|   --------------------+------------------------------+----------------------------------|
|   Kernel Architecture | Shared Host Kernel           | Dedicated Lightweight Hypervisor |
|                       | (Namespace & Job Objects)    | Utility VM Kernel per container  |
|   OS Version Match    | STRICT requirement: Host OS  | FLEXIBLE: Allows running mismatched|
|                       | build must match image build | container OS builds on host kernel|
|   Security Boundary   | Trust boundary: Suitable for | Hostile multi-tenancy boundary:  |
|                       | single-tenant enterprise apps| Strong hardware-level isolation  |
|   Startup Time & Perf | Milliseconds; highest density| Seconds; slight memory overhead  |
|                       | and raw execution speed      | per utility VM partition         |
|   Docker CLI Flag     | --isolation=process          | --isolation=hyperv               |
+-----------------------------------------------------------------------------------------+

[!IMPORTANT] Host OS Build Matching in Process Isolation: Under Process Isolation, the host operating system kernel and the container base image build must match exactly (e.g., a Windows Server 2022 build 20348 container image running on a Windows Server 2022 build 20348 host). Running a Windows Server 2019 container image on a Windows Server 2022 host requires Hyper-V Isolation.

2. Windows Base Container Images & Dockerfile Authoring

Microsoft maintains official Windows base container images in the Microsoft Container Registry (mcr.microsoft.com):

+-----------------------------------------------------------------------------------------+
|                        WINDOWS BASE CONTAINER IMAGES HIERARCHY                          |
|                                                                                         |
|   IMAGE REPOSITORY              APPROX. SIZE   TARGET WORKLOADS & RUNTIMES              |
|   ----------------------------+--------------+------------------------------------------|
|   mcr.microsoft.com/windows/  | ~100 - 300 MB| Cloud-native .NET 6/8/9, Node.js, Go,    |
|   nanoserver                  | (Compressed) | Python. 64-bit only; no GUI, no WOW64.   |
|   ----------------------------+--------------+------------------------------------------|
|   mcr.microsoft.com/windows/  | ~1.5 - 2 GB  | Full .NET Framework (3.5/4.8), IIS, WCF, |
|   servercore                  | (Compressed) | PowerShell 5.1, COM+, Windows Services.  |
|   ----------------------------+--------------+------------------------------------------|
|   mcr.microsoft.com/windows/  | ~3.1 GB      | Full Windows Server API set, GPU accel., |
|   server                      |              | no IIS conn. limits. Needs a WS2025 host.|
|   ----------------------------+--------------+------------------------------------------|
|   mcr.microsoft.com/windows   | ~3.4 GB      | Full Windows client API surface; DirectX |
|                               |              | and graphics libs. Not on WS2025.        |
+-----------------------------------------------------------------------------------------+

[!NOTE] Microsoft sizes the windows/server image at roughly 3.1 GB and the windows image at roughly 3.4 GB — the Windows Server image is the smaller of the two, inherits Server Core's reliability improvements, adds GPU acceleration support and removes IIS connection limits. The windows image isn't available for Windows Server 2025. Image tagging, registry distribution and cleanup are covered in section 8.6.

Preparing Windows Server as a Container Host

# Install the Containers and Hyper-V Windows features
Install-WindowsFeature -Name Containers, Hyper-V -IncludeManagementTools

# Install containerd runtime via Microsoft PowerShell script
Invoke-WebRequest -UseBasicParsing "https://aka.ms/install-containerd.ps1" -OutFile "install-containerd.ps1"
.\install-containerd.ps1

# Verify containerd service status
Get-Service containerd

Multi-Stage Dockerfile Authoring for Windows

# escape=`
# Multi-stage build: Compile on Server Core SDK, deploy on minimal Nano Server
FROM mcr.microsoft.com/dotnet/sdk:8.0-windowsservercore-ltsc2022 AS build-env
WORKDIR /app

# Copy project files and restore dependencies
COPY *.csproj ./
RUN dotnet restore

# Copy source files and build release binaries
COPY . ./
RUN dotnet publish -c Release -o /app/out

# Runtime stage: Lightweight Nano Server
FROM mcr.microsoft.com/windows/nanoserver:ltsc2022
WORKDIR /app
COPY --from=build-env /app/out ./

# Expose web service port and configure entrypoint
EXPOSE 8080
ENV ASPNETCORE_URLS=http://+:8080
ENTRYPOINT ["dotnet", "WebApiApp.dll"]

[!TIP] **Dockerfile Escape Directive (# escape=\``):** In Windows Dockerfiles, the standard backslash ` character is used as the file system directory separator. Adding # escape=\`` at the very first line configures the backtick ``` ``` as the escape character, preventing conflicts with Windows file paths.