Review: Windows Server containers are new and strange

Microsoft’s Docker-driven container feature works as advertised, but comes with a steep learning curve

At a Glance

Containers have been all the rage in the open source world for a number of years, but noticeably absent from Windows until now. In Windows Server 2016, Microsoft released its own container capabilities. Furthermore, Microsoft has given its customers the flexibility of operating containers at the Windows Server level or at the Hyper-V level.

Before I go on, let me take just a moment to explain the basic concept of a container. Containers are a form of virtualization, but they are quite different from virtual machines. Virtual machines use hardware virtualization to allow multiple OS instances to run side by side, isolated from one another by the virtual machine structure.

In contrast, containers don't include their own operating system but share a common OS image. As such, a container contains only application and service binaries and the libraries and configuration files those binaries require. For example, a Windows Server container would contain things like registry entries and application binaries. 

As previously mentioned, Windows Server 2016 allows for the creation of Windows Server containers and Hyper-V containers. The two container types are nearly identical to one another, but there is one important difference between the two.

It isn’t always acceptable for two containers to share a common OS kernel. There may be security requirements that mandate total isolation between two workloads, or a workload’s functional requirements may mandate the use of two different OS kernels (such as a Nano Server kernel and a Server Core kernel).

Unlike Windows Server containers, Hyper-V containers place the host OS kernel inside of a Hyper-V VM. Thus multiple host OS kernels can be used in parallel, and isolated from one another through hardware virtualization. Otherwise Windows Server containers and Hyper-V containers work the same way, and you manage them with the same tools.

Getting started with Windows containers

The first step to deploying Windows Server containers is to install the container feature, and then reboot the server. As you can see in Figure 1, the process of installing the Container feature is no different from installing any other Windows Server feature.

windows containers 01 IDG

Figure 1

The installation and configuration process gets a little bit tricky at this point. Some of the procedures used to get a container up and running have changed since the days of Windows Server 2016 Technical Preview, and much of the online documentation has not yet caught up.

The next thing that you will have to do before you can create a container is to install Docker. Docker is the management tool that is used to create and run Windows Server and Hyper-V containers. You can install Docker by entering the following commands:

Install-Module DockerMsftProvider
Install-Package -Name docker -ProviderName DockerMsftProvider

You can see what the installation process looks like in Figure 2. When the installation completes, you will need to reboot the server.

windows containers 02 rev IDG

Figure 2

When the server restarts, you will need to make sure that the Docker service is running. To do so, use the following command:

get-service docker

If the service is stopped, then you can start the service by typing:

start-service docker

You can then use these commands to confirm that the Docker service is running and functioning as expected:

get-service docker
docker version

You can see these commands in action in Figure 3.

windows containers 03 rev IDG

Figure 3

It is worth noting that Docker commands are case sensitive. In most cases, the commands must be entered in lower case to avoid receiving an error message.

Once Docker is up and running, you will need to install the base container image, and then restart the Docker service. The command used to install the base image varies depending on whether you decide to use a Windows Server Core image or a Nano Server image. This command is used for install a base Windows Server Core image:

docker pull Microsoft/windowsservercore

This command is used to install a base Nano Server image:

docker pull Microsoft/nanoserver

Regardless of which type of base image you deploy, you will have to restart the Docker service once the base image has been installed. At that point, your container host should be ready for use. You can verify that the images have been correctly installed by entering the docker images command. For instance, Figure 4 shows a Windows Server Core image that is ready for use.

windows containers 04 rev IDG

Figure 4

Creating a container from the base image is relatively easy to do. To create a Docker container, you will need to use the docker run command, along with the name of the base image that you want to use, and the name of the command that you want to run inside of the container. Add the -it switch if you want the container to be interactive. There are many other switches available that we won't get into here, but you can access these switches by entering the docker --help command.

The following command line will create a Windows Server Core container and execute the shell command, landing you at the command prompt:

docker run -it Microsoft/windowsservercore cmd

If you look at Figure 5, you can see that the command prompt window has opened inside of PowerShell. This prompt is inside the Windows Server Core container that we have just created.

windows containers 05 rev IDG

Figure 5

It is easy to think of the container shown in the figure above as being like a VM running a single application (the command prompt window). While that analogy is at least somewhat fitting, there is another key difference between containers and virtual machines that you need to be aware of.

Containers are meant to be highly dynamic. They can be created, destroyed, and recreated easily on a whim. In fact, containers tend to be temporary structures, created from scratch whenever they are needed. The essential concept to keep in mind is that containers only exist for as long as the application within the container is running.

To illustrate this point, I typed exit to exit the Command Prompt window, effectively terminating the container. I then used the same command that I used earlier to create another container. From a different PowerShell window, I entered the following command:

docker ps -a

This command lists the machine’s containers. It lists running containers, and those containers that have been exited. If you look at Figure 6, you can see that the container at the bottom of the list was created 12 minutes ago, and was terminated 8 minutes ago. In contrast, the first container on the list was created about a minute ago, and is still running.

windows containers 06 IDG

Figure 6

Thoughts on Windows containers

Working with Windows Server containers will be a completely new experience to most seasoned Windows administrators. Docker uses its own set of commands that are vastly different from the Windows command prompt and PowerShell commands that we are all accustomed to.

When you combine this new command set with a concept that is completely different from anything in Windows in the past, and throw in Microsoft documentation that is difficult to follow, it makes for a steep learning curve. On the plus side, Windows Server containers behave much like their Linux counterparts, and Linux containers have been around for a long time. This will get easier. 

But as I work with Windows containers, I just can’t help but to get the feeling that Microsoft is still trying to figure out where containers fit into its current ecosystem. Perhaps the best evidence of this is the inability to manage Windows Server containers through System Center.

Overall, I think that Microsoft has done a decent job on its container feature. This is Microsoft’s first attempt at supporting containers, and Windows Server containers seem to be nearly as good as the containers that are used in the open source world, although I admittedly have had very little experience with Linux containers.

What Microsoft needs to do now is to provide its customers with better documentation on the container feature, with plenty of step-by-step tutorials. Until that happens, Windows admins are unlikely to get the full benefit from their containers. Microsoft also needs to extend the System Center suite so that customers can use the same tools to manage containers as they use to manage their other Windows resources.


Cost: Microsoft offers two different editions of Windows Server 2016. Windows Server 2016 Standard Edition is designed for low density, or non-virtualized environments, and retails for $882. Standard Edition allows for up to two Hyper-V containers, or an unlimited number of Windows Server containers. Windows Server 2016 Datacenter Edition retails for $6115, but allows for an unlimited number of Hyper-V and Windows Server containers.

At a Glance
  • Microsoft’s container feature works as advertised, but comes with a steep learning curve and documentation that leaves a lot to be desired.


    • The container feature is included with the Windows Server operating system
    • Containers can be managed using the Docker command set
    • Containers can be flexibly deployed either through Windows Server or Hyper-V


    • Containers are very non-intuitive, and have a steep learning curve
    • Microsoft’s container-related documentation is incomplete and difficult to follow

Copyright © 2017 IDG Communications, Inc.