Run Docker Containers on Windows Server 2025

Most guides for Docker on Windows Server still tell you to run Install-Module DockerMsftProvider. That command has been dead since May 2023, when Microsoft shut down the service behind it. The supported route today is a PowerShell script from Microsoft that enables the Containers feature and installs Docker CE (the open source Moby engine) from the official static builds, so you get a real docker CLI and a dockerd Windows service.

Original content from computingforgeeks.com - post 8412

We install that engine, pull the Server 2025 base images and run them under both isolation modes, so you can see which older images still start. Then we build an IIS image, publish it on a host port, and show what happens when you try Linux containers on Windows Server. Every output below was captured on Windows Server 2025 Datacenter with Docker CE 29.9.2 in October 2026.

Which Docker engine runs on Windows Server

Docker CE installed by the Microsoft script is the free choice, and it is the one we use here. The Windows containers setup docs list three runtimes for Windows Server: Moby (Docker CE), the Mirantis Container Runtime and containerd. Docker Desktop is not one of them, because the Docker Desktop install page says it does not support server versions of Windows. Where each option stands in October 2026:

Option	Status on Server 2025	Who it suits
Docker CE via install-docker-ce.ps1	Supported install path in Microsoft’s docs, free, community support only	Labs, CI runners, most self-managed hosts
Mirantis Container Runtime	Commercial, the vendor-supported engine	Shops that need a support contract, including vendor-supported Swarm
Docker Desktop	Not supported on Windows Server	Windows 10 and 11 workstations only
DockerMsftProvider / Install-Package docker	Deprecated, backend shut down 23 May 2023	Nobody; old guides still show it

When Microsoft dropped the old provider, its announcement said Moby does not formally support several enterprise features that MCR has, and MCR is the one that comes with a vendor to call. If your organisation needs that when a container host breaks at 2 a.m., price MCR. For everything else, the steps below are all you need.

Install Docker CE on Windows Server 2025

The install-docker-ce.ps1 script does three jobs. It enables the Windows Containers feature, downloads the newest Docker static zip from download.docker.com into C:\Program Files\Docker, and registers dockerd as a Windows service. You need these before you start:

• Windows Server 2025 Standard or Datacenter, Desktop Experience or Core
• An elevated PowerShell session
• Outbound HTTPS to raw.githubusercontent.com, download.docker.com and mcr.microsoft.com
• 25 GB or more free on C: (the images in this guide add up to about 12 GB)

If you do not have a server yet, our Windows Server 2025 installation guide gets you to a login prompt. Download the script from the microsoft/Windows-Containers repository on GitHub, and note that the branch name really is Main with a capital M.

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -OutFile install-docker-ce.ps1

Run it from the same elevated session. Our lab launched it from powershell.exe -ExecutionPolicy Bypass, so if a Group Policy such as AllSigned blocks the script on your server, start the session the same way. On a server without the Containers feature, the first pass only enables the feature, because the feature install itself needs a restart before Docker can use it. So expect two runs with a restart between them, and pass -NoRestart so you choose when the server goes down:

.\install-docker-ce.ps1 -NoRestart

Without the flag, the script registers a scheduled task called ContainerBootstrap and restarts the server at once, and the task only resumes the install at an interactive logon, so an SSH or WinRM session still has to run it again by hand. We ran it with -NoRestart over a remote session (as SYSTEM, which is why the download paths below sit in the system profile rather than in C:\Users\<you>). It stopped at the reboot and printed this after 130 seconds:

Querying status of Windows feature: Containers...
Enabling feature Containers...
You must restart this server to finish the installation process.
A reboot is required; stopping script execution

On a production box that flag lets you pick the reboot window yourself. When you are ready, restart, then open an elevated PowerShell again and run .\install-docker-ce.ps1 -NoRestart a second time.

Restart-Computer -Force

After the reboot, the second pass skips the feature, downloads Docker and starts the service. It took 56 seconds on our VM, and the log shows which version it picked:

Querying status of Windows feature: Containers...
Feature Containers is already enabled.
DOCKER default
Checking Docker versions
Downloading https://download.docker.com/win/static/stable/x86_64/docker-29.9.2.zip to C:\WINDOWS\system32\config\systemprofile\DockerDownloads\docker-29.9.2.zip
Installing Docker... C:\WINDOWS\system32\config\systemprofile\DockerDownloads\docker-29.9.2\docker\docker.exe
Installing Docker daemon... C:\WINDOWS\system32\config\systemprofile\DockerDownloads\docker-29.9.2\docker\dockerd.exe
Adding C:\Program Files\Docker to the system PATH...
Configuring the docker service...
Waiting for Docker daemon...
Successfully connected to Docker Daemon.
The following images are present on this machine:
IMAGE   ID             DISK USAGE   CONTENT SIZE   EXTRA

Script complete!

By default the script takes the first version in a text sort of the download listing, which is not always the newest (a future 29.10 would sort below 29.9). When you build more hosts later and want them all on the same engine, pin the version on the first run of each fresh host, and add -HyperV if you already know you want Hyper-V isolation (more on that below). It is the same two-pass flow with a reboot in between, and we did not test these two flags in the lab:

# https://download.docker.com/win/static/stable/x86_64/
.\install-docker-ce.ps1 -DockerVersion 29.9.2 -HyperV -NoRestart

Do not expect the script to upgrade an existing install, though. Before it downloads anything it checks whether a service named docker exists, and if it does it prints Docker is already installed. and skips the engine entirely. Upgrading means replacing docker.exe and dockerd.exe in C:\Program Files\Docker from a newer zip on the Docker static download page with the service stopped. We did not run an upgrade in this lab, so try yours on a spare host before you touch production.

Verify the Docker engine

Open a new PowerShell window first, because the script added C:\Program Files\Docker to the machine PATH and an old window will not see it. Then check that the client and the daemon both answer.

docker version

Both halves should report the same version and windows/amd64. If you only get the client section followed by an error about the named pipe, the CLI is installed but the service is not running, so start it with Start-Service docker and try again. Our host answered on both halves:

Client:
 Version:           29.9.2
 API version:       1.56
 Go version:        go1.26.10
 Git commit:        a82e528
 Built:             Tue Oct 20 19:44:07 2026
 OS/Arch:           windows/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.9.2
  API version:      1.56 (minimum version 1.40)
  Go version:       go1.26.10
  Git commit:       0367cbe
  Built:            Tue Oct 20 19:40:53 2026
  OS/Arch:          windows/amd64
  Experimental:     false

Next, docker info tells you how the host will run containers. Three lines matter on Windows (the storage driver, the default isolation and the OS build), because the build decides which images you can run with process isolation.

docker info

We trimmed the output to the lines that differ from a Linux host, since plugins, registries and CPU counts read the same on both. The isolation and build lines are the ones you will come back to.

 Storage Driver: windowsfilter
 Default Isolation: process
 Kernel Version: 10.0 26100 (26100.1.amd64fre.ge_release.240331-1435)
 Operating System: Microsoft Windows Server Version 24H2 (OS Build 26100.32230)
 OSType: windows
 Docker Root Dir: C:\ProgramData\docker
 Product License: Community Engine

Default Isolation: process is the Windows Server default, and Windows 10 and 11 default to Hyper-V instead. Images, layers and volumes live under C:\ProgramData\docker, and the daemon reads its settings from C:\ProgramData\docker\config\daemon.json. The script wrote only one key there, "hosts": ["npipe://"], so the engine listens on the local named pipe and not on TCP. Leave it that way unless you set up TLS, since an open TCP socket on port 2375 hands anyone on the network full control of the host.

We renamed the lab host DOCKER01 before installing, because the name shows up in docker info and in the page the IIS container serves later on. The full version check on that box looked like this:

Behind the CLI is an ordinary Windows service called docker, so Restart-Service docker and Get-Service docker work as you would expect. On our VM it was running again after a later reboot without any help.

Pull Windows Server 2025 base images

Windows containers need a Windows base image, and Microsoft publishes them on the Microsoft Artifact Registry (mcr.microsoft.com) with no latest tag. You pick the tag that matches your host, which for Server 2025 is ltsc2025. Nano Server is the small one for .NET and Go binaries, and Server Core is the one most apps need because it carries PowerShell, .NET Framework and the full Win32 API. Pick by what the app needs at run time:

• nanoserver:ltsc2025 for self-contained .NET and Go binaries
• servercore:ltsc2025 for .NET Framework, IIS and most MSI installers
• windows/server:ltsc2025 only for apps that need APIs missing from Server Core

Pull the two you are most likely to use. The full windows/server image is far bigger than Server Core, so leave it until an app proves it needs it.

docker pull mcr.microsoft.com/windows/nanoserver:ltsc2025
docker pull mcr.microsoft.com/windows/servercore:ltsc2025

Be patient with Server Core. On our lab link the Nano Server pull took 105 seconds and Server Core took 1,087 seconds, just over 18 minutes, and the remote session went quiet for long stretches while it ran. We also pulled two older Nano Server tags, ltsc2022 and 1809, for the isolation tests further down. List what is on the host.

docker images

Sizes on disk after extraction:

IMAGE                                           ID             DISK USAGE   CONTENT SIZE   EXTRA
mcr.microsoft.com/windows/nanoserver:1809       84c408bfefba        266MB             0B
mcr.microsoft.com/windows/nanoserver:ltsc2022   81353e8694c9        303MB             0B
mcr.microsoft.com/windows/nanoserver:ltsc2025   bd66d3cd2318        487MB             0B
mcr.microsoft.com/windows/servercore:ltsc2025   1bb598526918       5.58GB             0B        

Those 5.58 GB are why Windows container hosts need bigger disks than Linux ones. Every Server Core based image you build shares those base layers, so the cost is paid once per host per base version, not once per image.

Run a Windows container

With an image on the host, docker run works the way it does on Linux. Start with Nano Server, because it is the smallest image and fails fastest if something is wrong with the host.

docker run --rm mcr.microsoft.com/windows/nanoserver:ltsc2025 cmd /c ver

Our host was on build 26100.32230, yet the container reported the newer patch level baked into the October image:

Microsoft Windows [Version 10.0.26100.33674]

A different patch level on the same build (26100) is fine for process isolation, so you do not have to patch the host and rebuild every image in lockstep. Server Core gives you full PowerShell inside the container.

docker run --rm mcr.microsoft.com/windows/servercore:ltsc2025 powershell -Command "(Get-ComputerInfo).OsName; hostname"

Inside, the hostname is the short container ID, not the host name, so scripts that read $env:COMPUTERNAME to pick a config will see a different value in every container:

Microsoft Windows Server 2025 Datacenter
9346420779ca

For anything long-running, start it detached and check which isolation mode Docker actually used, because docker ps does not show it.

docker run -d --name iso-test mcr.microsoft.com/windows/nanoserver:ltsc2025 ping -t localhost
docker inspect --format '{{.HostConfig.Isolation}}' iso-test

With no --isolation flag, the answer on Windows Server is process. Clean up with docker rm -f iso-test afterwards. If you already know Docker on Linux, our Docker cheat sheet covers the everyday commands, and almost all of them behave the same here.

Choose process or Hyper-V isolation

Process isolation shares the host kernel, like a Linux container, so it is fast and cheap but only works when the image’s Windows build is close enough to the host’s. Hyper-V isolation boots each container inside a small utility VM with its own kernel, which lets older images run on a newer host at the cost of memory and start time. The version compatibility table for a Server 2025 host matched what we saw in the lab.

Image base	Process isolation	Hyper-V isolation	Our result on 26100
ltsc2025 (26100)	Yes	Yes	Ran under both modes
ltsc2022 (20348)	Yes	Yes	Started with process isolation
1809 / ltsc2019 (17763)	No	Yes	Process failed with 0xc0370101, Hyper-V ran

Server 2022 images are the exception that helps most during a migration: nanoserver:ltsc2022 started with --isolation=process on our 2025 host, so you can move hosts first and rebuild images later. Anything older fails under process isolation.

docker run --rm --isolation=process mcr.microsoft.com/windows/nanoserver:1809 cmd /c ver

The 2019 image is refused before it starts. Docker passes the request to the Host Compute Service (HCS), and HCS compares the image build with the host kernel, so the error comes from Windows rather than from Docker:

docker: Error response from daemon: container 7b3df8182c1fbf36550e80ffad8a56978e3681095c7af7253443cc8d4e119914 encountered an error during hcs::System::Start: failure in a Windows system call: The container operating system does not match the host operating system. (0xc0370101)

The fix is --isolation=hyperv, but that flag needs the Hyper-V role, which the default script run does not install. Without it the same image fails with a much less helpful message:

docker: Error response from daemon: hcs::CreateComputeSystem 1ec17137f54dc9e1626c1855dfce8028e31006ccc897d6deeb2c3d176a0b9727: The request is not supported.

Keep process isolation as the default for images you build on the current base. A kernel per container is a much harder boundary than a shared one, so Hyper-V isolation earns its cost in three cases:

• Old ltsc2019 or ltsc2016 images you cannot rebuild yet
• Workloads from a team or vendor you do not fully trust
• Multi-tenant hosts where one container must never see another’s processes

Licensing matters as well. According to the Windows containers FAQ, Standard edition allows unlimited process-isolated containers but only two Hyper-V isolated ones, while Datacenter has no limit on either.

Enable Hyper-V isolation

Hyper-V isolation needs the Hyper-V role on the host and a reboot, and on a physical server that is all. Inside a VM, the hypervisor underneath must also expose virtualization extensions to the guest. We ran Proxmox with the CPU type set to host. On a Hyper-V parent, shut the VM down and run Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true on the physical host, then start the VM (we did not test that side). Check that the server can see the extensions before you spend a reboot on the role.

Get-CimInstance Win32_Processor | Select-Object Name, VirtualizationFirmwareEnabled, VMMonitorModeExtensions

Both flags have to read True, as they did on our i7-1165G7 lab VM. On bare metal that already runs Hyper-V or virtualization-based security, Windows reports them as False even though everything works. Inside a VM, you confirm it on the hypervisor side instead (the Proxmox CPU type, or the VM processor settings on a Hyper-V parent), because that is where nested virtualization is switched on. Our Proxmox setup is a lab configuration: Microsoft does not support Hyper-V on top of a non-Microsoft hypervisor, so run production Hyper-V isolation on bare metal or on a Hyper-V parent. Install the role with its management tools.

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools

It took 413 seconds on our VM, which is long enough that you should plan it into a maintenance window. Nothing changes until the restart, so Docker keeps running process-isolated containers in the meantime:

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes            SuccessRest... {Hyper-V, Hyper-V Module for Windows Power...
You must restart this server to finish the installation process.

Restart the server. The first boot after adding Hyper-V is slow because Windows now starts under the hypervisor, and on our nested VM the plain restart hung and needed a hard reset from Proxmox. The Docker service came back on its own afterwards. Now the 2019 image that failed earlier runs:

docker run --rm --isolation=hyperv mcr.microsoft.com/windows/nanoserver:1809 cmd /c ver

Now the version is the 2019 build, because the container boots its own 17763 kernel inside the utility VM:

Microsoft Windows [Version 10.0.17763.9378]

The cost shows up in start time and memory. We ran the same Nano Server 2025 image both ways and timed each docker run on the nested VM:

Run	Isolation	Time to output	Private working set (docker stats)
nanoserver:ltsc2025	process	15.1 s	33.92 MiB
nanoserver:ltsc2025	hyperv	98.7 s	266.3 MiB
nanoserver:1809	hyperv	85.2 s	not measured

Treat the Hyper-V times as worst case, because nested virtualization on a laptop-class i7 makes every utility VM boot slower than it would on bare metal. The ratio is the point: a Hyper-V isolated container needed about 8 times the memory of the same image under process isolation, and it was several times slower to start. You can also see the difference from the host. With one container of each kind running ping -t localhost, the host’s process list shows only one PING process, the one from the process-isolated container, while the Hyper-V one runs inside its utility VM and never appears. Start one of each:

docker run -d --name hv1 --isolation=hyperv mcr.microsoft.com/windows/nanoserver:ltsc2025 ping -t localhost
docker run -d --name pr1 --isolation=process mcr.microsoft.com/windows/nanoserver:ltsc2025 ping -t localhost

Then ask Docker how each one runs, and ask Windows which ping processes it can see:

docker inspect --format '{{.Name}} {{.HostConfig.Isolation}}' hv1 pr1
Get-Process ping -ErrorAction SilentlyContinue | Select-Object Id, ProcessName, SessionId | Format-Table -AutoSize

Two containers, one host process. The hv1 ping is invisible to the host, which is the whole point of the stronger boundary:

/hv1 hyperv
/pr1 process

  Id ProcessName SessionId
  -- ----------- ---------
2404 PING                2

The same story in one terminal, from the refused 2019 image to the two isolation modes side by side:

To make Hyper-V the default for every container on a host, add "exec-opts": ["isolation=hyperv"] to C:\ProgramData\docker\config\daemon.json next to the existing hosts key and restart the docker service (Microsoft documents that key; we did not test it). We left the default at process isolation and used the flag per container, which is what we’d do on most hosts.

Build and publish an IIS container

Most Windows containers in the wild are IIS sites or .NET Framework apps, so a two-line Dockerfile on Microsoft’s IIS image is a realistic first build. The IIS image is 5.72 GB on disk, and on our link it took 1,661 seconds, close to 28 minutes, because only one of its layers was shared with the Server Core image already on the host:

docker pull mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2025

Create a folder for the build with a page to serve. We used C:\lab\site:

New-Item -ItemType Directory -Force C:\lab\site
Set-Content -Path C:\lab\site\index.html -Value '<h1>Hello from a Windows container on DOCKER01</h1>'

Write the Dockerfile into the same folder. The file is two lines, so one Set-Content call does it, with PowerShell’s `r`n as the line break and no Notepad step that might quietly save it as Dockerfile.txt:

Set-Content -Path C:\lab\site\Dockerfile -Value "FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2025`r`nCOPY index.html C:/inetpub/wwwroot/index.html"
Get-Content C:\lab\site\Dockerfile

Forward slashes in the destination path work in Windows Dockerfiles and save you from escaping backslashes. The file should read:

FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2025
COPY index.html C:/inetpub/wwwroot/index.html

Build the image and start it with host port 8080 mapped to port 80 inside the container:

docker build -t mysite:1.0 C:\lab\site
docker run -d --name web -p 8080:80 mysite:1.0

The Windows engine still uses the classic builder, so the build log looks like Docker from a few years ago, with numbered steps and no BuildKit progress bars:

Sending build context to Docker daemon  3.072kB

Step 1/2 : FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2025
 ---> ad2f125de82f
Step 2/2 : COPY index.html C:/inetpub/wwwroot/index.html
 ---> a52c56cb92a3
Successfully built a52c56cb92a3
Successfully tagged mysite:1.0

Give IIS 15 seconds or so to start inside the container, then request the page through the published port:

docker ps
(Invoke-WebRequest -UseBasicParsing http://localhost:8080).Content

The container is up with 0.0.0.0:8080->80/tcp, and the page comes back from IIS:

CONTAINER ID   IMAGE        COMMAND                   CREATED          STATUS          PORTS                  NAMES
48ba05db5eac   mysite:1.0   "C:\\ServiceMonitor.e…"   21 seconds ago   Up 15 seconds   0.0.0.0:8080->80/tcp   web
<h1>Hello from a Windows container on DOCKER01</h1>

Containers sit on the default nat network, and ours got 172.28.197.140 behind a 172.28.192.1 gateway on the host. That is a private NAT range, so other machines reach the site through the published port on the server’s own address, not through the container IP. We tested from the server itself. For clients on the network, allow TCP 8080 inbound in Windows Defender Firewall as described in our guide to opening a port in Windows Server Firewall. If you would rather run the site on IIS installed directly on the server, our IIS virtual directory guide covers that side.

Run Linux containers on Windows Server

You can’t run Linux containers with this engine. A Windows-mode Docker daemon asks registries for a windows/amd64 image, and images like ubuntu or alpine don’t publish one:

docker pull ubuntu:24.04

The pull fails on the manifest before a single layer downloads. That makes it cheap to hit, but it also means a script that pulls a mix of Linux and Windows images stops at the first Linux one, so split those jobs by host OS. Our host printed this:

24.04: Pulling from library/ubuntu
no matching manifest for windows(10.0.26100)/amd64 in the manifest list entries

The old workaround in many Windows Server Docker guides, LCOW with LCOW_SUPPORTED=1 and an experimental daemon, is gone. Docker deprecated LCOW in 20.10 and removed it in Docker Engine 23.0, so on 29.x those settings do nothing. Docker Desktop’s Linux mode isn’t an option either, because Desktop isn’t supported on Windows Server.

That leaves a Linux kernel next to Windows. Server 2025 supports WSL 2 with a plain wsl --install, and from there you can run Podman or Docker Engine inside the distro; our guide to running Podman on Windows Server with WSL2 walks through that setup. For production Linux workloads we’d skip WSL and give them a small Linux VM on the same Hyper-V host, which you can manage and patch like any other server. Either way, keep the Windows engine for Windows images only.

Troubleshoot Docker on Windows Server

All three errors below came up in our lab, and each one points at a different layer: the image build, the host roles, or the image’s operating system. Read the last part of each message first, because the useful words come after the container ID and the hcs:: call name.

Error: “The container operating system does not match the host operating system. (0xc0370101)”

The image was built on an older Windows build than process isolation allows on this host, here a 2019 (17763) image on a 2025 (26100) server. Rebuild the image FROM an ltsc2025 or ltsc2022 base if you own the Dockerfile. If you don’t, run it with --isolation=hyperv after installing the Hyper-V role. Pulling a different tag of the same image often fixes it too, because most publishers tag Windows images per base version.

Error: “hcs::CreateComputeSystem … The request is not supported.”

You asked for --isolation=hyperv on a host without the Hyper-V role. The message never mentions Hyper-V, which is why it costs people time. Confirm with Get-WindowsFeature Hyper-V; if it reads Available instead of Installed, install the role and reboot as shown above. On a VM, also confirm nested virtualization is exposed, or the role won’t help.

Error: “no matching manifest for windows(10.0.26100)/amd64 in the manifest list entries”

The image has no Windows variant, which means it’s a Linux image. Nothing on the Windows engine fixes that: look for a Windows tag of the same software on Docker Hub or MCR, or run the image on Linux through WSL 2 or a Linux VM as covered in the previous section.

One more thing that looks like a hang but isn’t: the first docker run of a freshly pulled Server Core image can sit for a minute or more while Windows prepares the 5.58 GB base layer, and our first attempt took long enough that the remote session gave up on it. Running the same command again completed normally, so pull and run base images once while you build the host, not in the middle of a deployment.