All posts by Craig Wilhite

Windows Server 2019 Now Available


Windows Server 2019 is once again generally available. You can pull the new Windows Server 2019 images—including the new ‘Windows’ base image—via:

docker pull
docker pull
docker pull

Just like the Windows Server 2016 release, the Windows Server Core container image is the only Windows base image in our Long-Term Servicing Channel. For this image we also have an ‘ltsc2019’ tag available to use:

docker pull

The Nanoserver and Windows base images continue to be Semi-Annual Channel releases only.

(2:02PM PST – All new Windows base images are live)


Q: I am seeing “no matching manifest for unknown in the manifest list entries” when I try to pull the image. What do I do?
A: Users will need to be running the latest version of Windows–Windows Server 2019 or Windows 10, October 2018 update–in order to pull and run the container images. Since older version of Windows do not support running newer version of containers, we disallow a user from pulling an image that they could not run.

MCR is the De Facto container source

You can now pull any Windows base image:tag combination from the MCR (Microsoft Container Registry). Whether you’re using a container based on the Windows Server 2016 release, version 1709, version 1803 or any tag in between, you should change your container pull references to the MCR source. Example:

#Here’s the old string for pulling a container
docker pull microsoft/windowsservercore:ltsc2016
docker pull microsoft/nanoserver:1709

#Change the string to the new syntax and use the same tag
docker pull
docker pull

Or, update your dockerfiles to reference the new image location:

#Here’s the old string to specify the base image
FROM microsoft/windowsservercore:ltsc2016

#Here’s the new, recommend string to specify your base image. Use whichever tag you’d like

We want to emphasize the MCR is not the place to browse for container images; it’s where you pull images from. Docker Hub continues to be the preferred medium for container image discovery. Steve Lasker’s blog post does a great job outlining the unique value proposition the MCR will bring for our customers.

The Windows Server 2019 VM images for the Azure gallery will be rolling out within the next few days and will come packaged with the most up-to-date Windows Server 2019 container images.

Deprecating the ‘latest’ tag

We are deprecating the ‘latest’ tag across all our Windows base images to encourage better container practices. At the beginning of the 2019 calendar year, we will no longer publish the tag; We’ll yank it from the available tags list.

We strongly encourage you to instead declare the specific container tag you’d like to run in production. The ‘latest’ tag is the opposite of specific; it doesn’t tell the user anything about what version the container actually is apart from the image name. You can read more about version compatibility and selecting the appropriate tag on our container docs.


For more information, please visit our container docs at What other topics & content would you like to see written about containers? Let us know in the comments below or send me a tweet.


Craig Wilhite (@CraigWilhite)

Incoming Tag Changes for Containers in Windows Server 2019

Windows Server 2019 is now generally available. We are thrilled for users to get their hands on all the work we’ve put into this latest edition of Windows Server. In addition to Windows Server 2019 delivering a ton of new containers features, there is an important change coming with regards to where a user gets Microsoft-authored container images.


  1. The “latest” tag will be changed from Windows Server 2016 to Windows Server 2019.
  2. New container image versions (such as Windows Sever 2019) will be published on Microsoft Container Registry (MCR) only.
  3. Already-live container images will continue to be updated on Docker Hub. We are working on making all existing images available on the MCR as well. We expect this process to be completed in the next few weeks.

The ‘latest’ Tag

Windows Server 2016 was the first Long Term Servicing Channel (LTSC) to ship with the containers feature. The ‘latest’ tag for our container images points to the latest LTSC. As such, it has pointed to Windows Server 2016. With the release of Windows Server 2019, this tag will point to the new latest LTSC—Windows Server 2019. This is important to be aware of if you are relying on using:

docker pull Microsoft/windowsservercore:latest

because it will no longer be a Windows Server 2016 versioned container. Please also note for Nano Server container, the current ‘latest’ tag is pointing to “Windows Server, version 1803”. With this release of Windows Server 2019, the ‘latest’ tag of Nano Server will be pointed to Windows Server 2019 as well.

With the feedbacks we heard in the past that changing this tag may break some scenarios, especially with automation, we are experimenting to delay changing the ‘latest’ tag till a week later. Please do take time and make necessary changes.

Microsoft Container Registry

Steve Lasker wrote a blog back in May about the new Microsoft syndicates container catalog, describing how Microsoft will start serving container images from, the Microsoft Container Registry (MCR), and syndicating the content describing the container images with Docker Hub and Red Hat.

I would encourage you to read the post if you’re interested in understanding the key benefits we see in moving to the MCR. Putting that aside, I’d like to focus on how this transition will impact the end user and address common questions. Let’s dive into the FAQ below.

How will I pull the NEW container images from Microsoft?

Here is how you can pull a container:

docker pull

This contrasts with how a user would pull a container prior to Windows Server 2019:

docker pull microsoft/windowsservercore:ltsc2016

What images will exist on the MCR?

Today, only new container images will live on the MCR, meaning the Windows Server 2019 container image version. You can continue to discover these images by browsing Docker Hub. The full pull commands for each image of the Windows Server 2019 release would be:

docker pull
docker pull

New container images will exist only on the MCR. Already-live images will continue to exist on Docker Hub.

We are working on making all Microsoft container images available on the MCR. This means for any existing image you get from Docker Hub today, you will be able to replace the string wholesale with the equivalent. Be on the lookout for future blog posts indicating when this transition will be completed. Since only Windows Server 2019 images are being pushed to the MCR for this week, the pull string identified in the repo information section of the container image on Docker Hub will remain the same.

What tags will exist on the MCR?

New container image tags will exist only on the MCR. Already-live tags will continue to exist Docker and eventually exist on the MCR at a later date.

New Tags

All newly created tags for new container images will exist only on the MCR. Example:

#This tag can ONLY be pulled from the MCR
docker pull
#This tag can ONLY be pulled from the MCR
docker pull

All newly created tags for already-live container images will continue to be published on Docker Hub. Example:

#This tag can continue to be pulled from Docker Hub
docker pull

Already-Live Tags

All already-published container images will continue to exist on Docker Hub. As an example, if you have a container image with tag ‘1803_KB4457128’, you can continue to pull the container from it’s original pull URL.

#you can still pull from Docker Hub, since the 1803 tag existed before the move to MCR
docker pull microsoft/windowsservercore:1803_KB4457128
#this will also work
docker pull

As state above, we are working to also make these older images available on the MCR at a later date.


This wraps up the important changes for containers arriving with Windows Server 2019. For more information, please visit our container docs at and stay tuned for later posts outlining all of the new container features in Windows Server 2019!


Craig Wilhite (@CraigWilhite)

Bringing Device Support to Windows Server Containers

When we introduced containers to Windows with the release of Windows Server 2016, our primary goal was to support traditional server-oriented applications and workloads. As time has gone on, we’ve heard feedback from our users about how certain workloads need access to peripheral devices—a problem when you try to wrap those workloads in a container. We’re introducing support for select host device access from Windows Server containers, beginning in Insider Build 17735 (see table below).

We’ve contributed these changes back to the Open Containers Initiative (OCI) specification for Windows. We will be submitting changes to Docker to enable this functionality soon. Watch the video below for a simple example of this work in action (hint: maximize the video).

What’s Happening

To provide a simple demonstration of the workflow, we have a simple client application that listens on a COM port and reports incoming integer values (powershell console on the right). We did not have any devices on hand to speak over physical COM, so we ran the application inside of a VM and assigned the VM’s virtual COM port to the container. To mimic a COM device, an application was created to generate random integer values and send it over a named pipe to the VM’s virtual COM port (this is the powershell console on the left).

As we see in the video at the beginning, if we do not assign COM ports to our container, when the application runs in the container and tries to open a handle to the COM port, it fails with an IOException (because as far as the container knew, the COM port didn’t exist!). On our second run of the container, we assign the COM port to the container and the application successfully gets and prints out the incoming random ints generated by our app running on the host.

How It Works

Let’s look at how it will work in Docker. From a shell, a user will type:

docker run --device="/"

For example, if you wanted to pass a COM port to your container:

docker run --device="class/86E0D1E0-8089-11D0-9CE4-08003E301F73"

The value we’re passing to the device argument is simple: it looks for an IdType and an Id. For this coming release of Windows , we only support an IdType of “class”. For Id, this is  a device interface class GUID. The values are delimited by a slash, “/”.  Whereas  in Linux a user assigns individual devices by specifying a file path in the “/dev/” namespace, in Windows we’re adding support for a user to specify an interface class, and all devices which identify as implementing this class   will be plumbed into the container.

If a user wants to specify multiple classes to assign to a container:

docker run --device="class/86E0D1E0-8089-11D0-9CE4-08003E301F73" --device="class/DCDE6AF9-6610-4285-828F-CAAF78C424CC" --device="…"

What are the Limitations?

Process isolation only: We only support passing devices to containers running in process isolation; Hyper-V isolation is not supported, nor do we support host device access for Linux Containers on Windows (LCOW).

We support a distinct list of devices: In this release, we targeted enabling a specific set of features and a specific set of host device classes. We’re starting with simple buses. The complete list that we currently support  is  below.

Device Type Interface Class  GUID
GPIO 916EF1CB-8426-468D-A6F7-9AE8076881B3
I2C Bus A11EE3C6-8421-4202-A3E7-B91FF90188E4
COM Port 86E0D1E0-8089-11D0-9CE4-08003E301F73
SPI Bus DCDE6AF9-6610-4285-828F-CAAF78C424CC

Stay tuned for a Part 2 of this blog that explores the architectural decisions we chose to make in Windows to add this support.

What’s Next?

We’re eager to get your feedback. What specific devices are most interesting for you and what workload would you hope to accomplish with them? Are there other ways you’d like to be able to access devices in containers? Leave a comment below or feel free to tweet at me.


Craig Wilhite (@CraigWilhite)