Update Windows Server containers

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016

As part of servicing Windows Server each month, we publish updated Windows Server Base OS container images on a regular basis. With these updates, you can automate building updated container images or manually update them by pulling the latest version. Windows Server containers don't have a servicing stack like Windows Server. You can't get updates within a container like you do with Windows Server. Therefore, every month we rebuild the Windows Server Base OS container images with the updates and publish the updated container images.

Other container images, such as .NET or IIS, will be rebuilt based on the updated Base OS container images and published monthly.

How to get Windows Server container updates

We update Windows Server Base OS container images in alignment with the Windows servicing cadence. Updated container images are published the second Tuesday of each month, which we sometimes refer to as our "B" release, with a prefix number based on the release month. For example, we call our February update "2B" and our March update "3B." This monthly update event is the only regular release that include new security fixes.

The server hosting these containers, called the container host or just the "host", can be serviced during additional update events other than "B" releases. To learn more about the Windows update servicing cadence, see our Windows update servicing cadence blog post.

New Windows Server Base OS container images go live shortly after 10:00am PST on the second Tuesday of each month in the Microsoft Container Registry (MCR), and the featured tags target the most recent B release. Some examples include:

• ltsc2019 (LTSC): docker pull mcr.microsoft.com/windows/servercore:ltsc2019
• 1909 (SAC): docker pull mcr.microsoft.com/windows/servercore:1909

If you're more familiar with Docker Hub than MCR, this blog post will give you a more detailed explanation.

For each release, the respective container image also gets published with two additional tags for the revision number and the KB article number for targeting specific container image revisions. For example:

• docker pull mcr.microsoft.com/windows/servercore:10.0.17763.1040
• docker pull mcr.microsoft.com/windows/servercore:1809-KB4546852

These examples both pull the Windows Server 2019 Server Core container image with the February 18 security release update.

For a complete list of Windows Server Base OS container images, versions, and their respective tags, see the following resources on Docker Hub:

• Windows Server
• Windows Server Core
• Nano Server

Monthly serviced Windows Server images released on Azure Marketplace by Microsoft also come with preinstalled Base OS container images. Find our more at our Windows Server Azure Marketplace pricing page. We usually update these images about five working days after the "B" release.

For a complete list of Windows Server images and versions, see Windows Server release on Azure Marketplace update history.

Host and container version compatibility

There are two types of isolation modes for Windows containers: Process isolation and Hyper-V isolation. Hyper-V isolation is more flexible when it comes to host and container version compatibility. To learn more, see Version compatibility and Isolation Modes. This section will focus on process-isolated containers unless stated otherwise.

When you update your container host or container image with the monthly updates, as long as the host and container image are both supported (Windows Server version 1809 or higher), the host and container image revisions don't need to match for the container to start and run normally.

However, you might encounter issues when using Windows Server containers with the February 11, 2020 security update release (also called "2B") or later monthly security update releases. See this Microsoft Support article for more details. These issues resulted from a security change that required an interface between user mode and kernel mode to change to ensure the security of your applications. These issues only happen on process isolated containers because process isolated containers share the kernel mode with the container host. This means container images without the updated user mode component were unsecured and incompatible with the new secured kernel interface.

We've released a fix as of February 18, 2020. This new release has established a "new baseline." This new baseline follows these rules:

• Any combination of hosts and containers that are both before 2B will work.
• Any combination of hosts and containers that are both after 2B will work.
• Any combination of hosts and containers on different sides of the new baseline won't work. For example, a 3B host and a 1B container won't work.

Let's use the March 2020 monthly security update release as an example to show you how these new compatibility rules work. In the following table, the March 2020 security update release is called "3B," the February 2020 update is "2B," and the January 2020 update is "1B."

For reference, the following table lists the version numbers for Base OS container images with 1B, 2B, and 3B monthly security update releases across different major OS releases from Windows Server 2016 to the latest Windows Server, version 1909 release.

Troubleshoot host and container image mismatches

Before you start, make sure sure to get familiar with the information in Version compatibility. This information will help you figure out whether your issue was caused by mismatching patches. When you've established mismatching patches as the cause, you can follow the instructions in this section to troubleshoot the issue.

Query the version of your container host

If you can access your container host, you can run the ver command to get its OS version. For example, if you run ver on a system that runs Windows Server 2019 with the latest Feb 2020 security update release, you'll see this:

Microsoft Windows [Version 10.0.17763.1039]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>ver

Microsoft Windows [Version 10.0.17763.1039]

If you don't have direct access to your container host, check with your IT admin. If you're running on the cloud, check the cloud provider's website to find out what container host OS version they're running. For example, If you are using Azure Kubernetes Service (AKS), you can find the host OS version in the AKS release notes.

Query the version of your container image

Follow these instructions to find out which version your container is running:

1. Run the following cmdlet in PowerShell:

   docker images
   

   The output should look something like this:

   REPOSITORY                             TAG                 IMAGE ID            CREATED             SIZE
   mcr.microsoft.com/windows/servercore   ltsc2019            b456290f487c        4 weeks ago         4.84GB
   mcr.microsoft.com/windows              1809                58229ca44fa7        4 weeks ago         12GB
   mcr.microsoft.com/windows/nanoserver   1809                f519d4f3a868        4 weeks ago         251M
   
   

2. Run the docker inspect command for the Image ID of the container image that isn't working. This will tell you which version the container image is targeting.

   For example, let's say we run docker inspect for an ltsc 2019 container image:

   docker inspect b456290f487c
   
       "Architecture": "amd64",
   
        "Os": "windows",
   
        "OsVersion": "10.0.17763.1039",
   
        "Size": 4841309825,
   
        "VirtualSize": 4841309825,
   

   In this example, the container OS version shows as 10.0.17763.1039.

   If you're already running a container, you can also run the ver command within the container itself to get the version. For example, running ver in a Server Core container image of Windows Server 2019 with the latest Feb 2020 security update release will show you this:

   Microsoft Windows [Version 10.0.17763.1040]
   (c) 2020 Microsoft Corporation. All rights reserved.
   
   C:\>ver
   
   Microsoft Windows [Version 10.0.17763.1040]