Windows Server containers: images, isolation and Docker

Start DC01 and SRV01. Take a snapshot of SRV01 called “Before containers”. Work on SRV01 in PowerShell as administrator.

1Install the container runtime

On SRV01, download and run Microsoft’s install script:

Set-Location C:\Scripts
Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1
.\install-docker-ce.ps1

The script enables the Containers feature and restarts SRV01 if needed. After the restart, sign in again; the script continues and installs Docker as a service. If it doesn’t resume by itself, run it once more.

Then check:

docker version --format "Client {{.Client.Version}} {{.Client.Os}}/{{.Client.Arch}} - Server {{.Server.Version}} {{.Server.Os}}/{{.Server.Arch}}"
Get-Service docker | Select-Object Status, StartType

You should see something like this:

Client 27.x.x windows/amd64 - Server 27.x.x windows/amd64

 Status StartType
 ------ ---------
Running Automatic

✅ Checkpoint: docker version shows a Windows client and server, and the docker service is Running.

2Pull an image and run a container

On SRV01:

docker pull mcr.microsoft.com/windows/nanoserver:ltsc2025
docker images
docker run --rm mcr.microsoft.com/windows/nanoserver:ltsc2025 cmd /c "hostname & ver"

You should see something like this:

REPOSITORY                             TAG        IMAGE ID       CREATED       SIZE
mcr.microsoft.com/windows/nanoserver   ltsc2025   4e2a1c8b9f03   2 weeks ago   300MB

7c3e9a21b4d6

Microsoft Windows [Version 10.0.26100.NNNN]

The container got its own random hostname, and its Windows version matches SRV01’s build 26100. --rm deletes the container when it exits; the image stays.

✅ Checkpoint: The Nano Server image is listed, and the container printed a random hostname and version 10.0.26100.

3Run a long-lived container and look inside

On SRV01:

docker run -d --name pinger mcr.microsoft.com/windows/nanoserver:ltsc2025 ping -t localhost
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"
docker exec pinger cmd /c "dir C:\ /b"
docker inspect --format "{{.HostConfig.Isolation}}" pinger
Get-Process -Name PING | Select-Object Id, ProcessName, SessionId

You should see something like this:

NAMES    STATUS         IMAGE
pinger   Up 8 seconds   mcr.microsoft.com/windows/nanoserver:ltsc2025

License.txt
Program Files
ProgramData
Users
Windows

process

  Id ProcessName SessionId
  -- ----------- ---------
4812 PING                2

The container has its own tiny C: drive. Isolation is “process”, so the container’s PING.EXE shows up in SRV01’s own process list, in its own session. That’s the difference from a VM, where you’d never see the guest’s processes on the host.

Stop and remove it:

docker logs pinger --tail 2
docker rm -f pinger

✅ Checkpoint: You saw the container’s files, its “process” isolation, and its PING process on the host, then removed it.

4Build your own image

On SRV01, create the build folder and files:

New-Item -ItemType Directory C:\Build -Force | Out-Null
'Hello from the SaatLab container image, version 1.0' | Set-Content C:\Build\hello.txt
@'
FROM mcr.microsoft.com/windows/nanoserver:ltsc2025
COPY hello.txt C:/app/hello.txt
CMD ["cmd", "/c", "type C:\\app\\hello.txt"]
'@ | Set-Content C:\Build\Dockerfile
docker build -t saatlab/hello:1.0 C:\Build
docker run --rm saatlab/hello:1.0

You should see this at the end:

Hello from the SaatLab container image, version 1.0

The Dockerfile is the recipe: start from Nano Server, add a file, set the default command. Anyone with the same Dockerfile and files builds the same image. In real projects, images are pushed to a registry such as Azure Container Registry and pulled by servers or Kubernetes nodes.

✅ Checkpoint: docker run saatlab/hello:1.0 prints the hello line.

5Keep data with a bind mount

On SRV01:

New-Item -ItemType Directory D:\Data\app -Force | Out-Null
docker run --rm -v D:\Data\app:C:\data mcr.microsoft.com/windows/nanoserver:ltsc2025 cmd /c "echo written by a container> C:\data\out.txt"
Get-Content D:\Data\app\out.txt

You should see this:

written by a container

The container is gone (because of --rm), but the file it wrote lives on in D:\Data\app on SRV01. Logs, uploads and databases always go in volumes or mounts like this.

✅ Checkpoint: D:\Data\app\out.txt exists on SRV01 after the container was removed.