Windows Containers & Docker Support On-Premises: Policy Deep Dive for Windows Server

Table of Contents

This document details Microsoft’s support guidelines for utilizing Windows Server containers in on-premises environments. It is crucial for organizations planning to adopt containerization strategies on their local infrastructure to understand these policies to ensure they operate within supported configurations and receive the necessary assistance when needed. This policy applies to various Windows versions, including Windows Server 2022, 2019, 2016, Windows 10, and Windows 11 across all editions. The information provided here serves as a comprehensive guide to navigating the support landscape for Windows Server containers.

Supported Configurations for Container Hosts¶

Microsoft defines the supported configurations for container hosts based on several key components. These components work together to ensure a stable and supported environment for running Windows Server containers. Understanding each of these configurations is vital for successful on-premises container deployment.

• Host Operating System: The foundation of any container environment is the host operating system. Microsoft supports Windows Server, Windows 10, and Windows 11 as valid host operating systems for Windows Server containers. Each of these operating systems offers different levels of support and features for containerization. It’s essential to choose the operating system that best aligns with your organization’s needs and infrastructure. Detailed system requirements for each OS can be found in the official Windows containers documentation.

• Hypervisor: The hypervisor plays a crucial role in container isolation and security. For Windows 10 and Windows 11, Hyper-V is a mandatory requirement to support containers. Windows Server, on the other hand, offers greater flexibility in hypervisor configurations. It can function as a container host with or without Hyper-V, depending on the desired container isolation mode and workload requirements. Hyper-V provides hardware-level virtualization, enhancing security and resource management for containers.

• Mirantis Container Runtime (MCR): Mirantis Container Runtime (MCR) is a critical third-party application for creating and managing containers on Windows Server. MCR is essential for deploying both Windows Server containers and Hyper-V isolated containers. It provides the necessary tools and functionalities to interact with the Windows container ecosystem. Organizations utilizing Windows Server for containerization in on-premises scenarios should ensure MCR is correctly installed and configured. Further details about MCR and its integration with Windows containers can be found in the Windows containers requirements documentation.

• ContainerD: ContainerD is another container runtime, particularly relevant for AKS Hybrid and AKS deployments. While Mirantis Container Runtime is emphasized for general Windows Server container usage, ContainerD is integral to Microsoft’s hybrid Kubernetes solutions. It is designed to be an industry-standard container runtime, focusing on simplicity, robustness, and portability. Organizations deploying AKS Hybrid or AKS on-premises will interact with ContainerD as the underlying container runtime.

• Docker Desktop: Docker Desktop for Windows is the officially supported distribution for running Docker containers on Windows 10 and Windows 11. It is primarily aimed at developers and smaller teams, providing a user-friendly interface and streamlined experience for container development and experimentation. Docker Desktop includes Docker Engine, Docker CLI, Docker Compose, and Kubernetes, making it a comprehensive toolset for local container management. It’s important to note that while Docker Desktop is supported on Windows 10 and 11, its support scope differs from the support for Windows Server container hosts.

• Container Type: Microsoft supports Windows Server containers with Hyper-V isolation. This isolation mode provides enhanced security and resource separation between containers and the host system. However, not all host configurations can support every container type. The choice of container type often depends on the specific application requirements, security considerations, and the host operating system’s capabilities. Understanding the nuances between different container types, such as process isolation and Hyper-V isolation, is crucial for designing a secure and efficient container environment. Refer to the documentation on container base images and Windows container version compatibility for detailed information on container types and their compatibility.

Note: The Linux Containers on Windows (LCOW) feature on Windows Server has been deprecated. This means that while it was previously possible to run Linux containers directly on Windows Server, this feature is no longer supported and should not be used in production environments. Organizations seeking to run Linux containers alongside Windows containers should explore alternative solutions like using a Linux VM on Hyper-V or leveraging AKS hybrid solutions.

Host Component Support¶

Windows Server containers running on supported Windows Server versions, whether on physical hardware or within virtual machines (VMs) on Hyper-V, receive comprehensive support. This support covers issues related to the operating system itself, the base container images provided by Microsoft, and the core container features. This ensures that organizations can confidently deploy and manage Windows Server containers knowing they have Microsoft’s backing for the underlying platform and essential components.

Furthermore, if you are running Windows Server containers on a Windows Server 2016 or higher VM that is hosted on a SVVP validated hypervisor, you also receive full support. SVVP (Server Virtualization Validation Program) validated hypervisors are third-party hypervisors that have been validated by Microsoft to ensure compatibility and support for Windows Server. This validation extends the support boundary to include VMs running on these validated hypervisors, providing flexibility for organizations using diverse virtualization platforms. The support scope remains the same, encompassing the operating system, base container images, and container features.

Supported Configurations for Windows Server Container Hosts¶

To successfully deploy Windows Server containers, particularly those utilizing Hyper-V isolation, the Mirantis Container Runtime (MCR) is a mandatory component. MCR acts as the container runtime engine on Windows Server, facilitating the creation, management, and execution of containers. Its installation is a prerequisite for setting up a Windows Server environment ready for containerization.

For detailed guidance on preparing Windows Server for containers, refer to the official documentation titled “Get started: Prep Windows for containers”. This documentation provides step-by-step instructions on installing and configuring MCR, along with other essential configurations needed to enable Windows Server as a robust container host. Properly setting up the environment, including MCR installation, is crucial for ensuring stability, performance, and supportability of your Windows Server container deployments.

Supported Container Types on Physical Container Host¶

When deploying containers on a physical Windows Server host, the choice of hypervisor directly influences the supported container types. The following table summarizes the container type support based on the presence of a hypervisor:

Hypervisor	Supported Container Types
None	Windows Server containers
Hyper-V	Hyper-V isolation and Windows Server containers

Explanation:

• No Hypervisor: If the physical Windows Server host is not running Hyper-V, it can only support Windows Server containers. In this mode, containers share the kernel with the host operating system. This is often referred to as process isolation. While offering density and performance benefits, process isolation provides a weaker security boundary compared to Hyper-V isolation.

• Hyper-V: When Hyper-V is enabled on the physical host, it unlocks support for both Hyper-V isolation and Windows Server containers. Hyper-V isolation provides a more robust security boundary by running each container in a lightweight virtual machine. This isolation mode is generally recommended for production environments where security and isolation are paramount. However, it comes with a slightly higher overhead compared to process isolation. The flexibility to choose between these two container types allows administrators to tailor their container deployments to specific workload needs and security requirements.

Supported Container Types on a Virtual Machine Container Host¶

When the container host itself is a virtual machine, the supported container types become more nuanced and depend on the underlying hypervisor of the VM host and whether nested virtualization is enabled. Nested virtualization allows running Hyper-V inside a VM, which is essential for Hyper-V isolated containers in a virtualized environment. The following table outlines the supported container types in various VM configurations:

VM Host Hypervisor	Guests OS	Guest Hypervisor	Supported Container Types
Hyper-V	Windows Server (full or core)	None	Windows Server containers
Hyper-V	Windows Server (full or core)	Hyper-V (must be running in nested virtualization mode)	Windows Server containers and Hyper-V isolated containers
SVVP validated hypervisor	Windows Server (full or core)	None (Hyper-V not supported on VMware ESX)	Windows Server containers

Explanation:

• Hyper-V Host, Windows Server Guest, No Nested Hyper-V: In this common configuration where a Windows Server VM is running on a Hyper-V host and nested virtualization is not enabled, only Windows Server containers are supported within the guest VM. Without nested virtualization, Hyper-V isolation is not possible inside the VM.

• Hyper-V Host, Windows Server Guest, Nested Hyper-V Enabled: If nested virtualization is enabled in the Hyper-V environment, the Windows Server guest VM can now run its own Hyper-V. This configuration supports both Windows Server containers and Hyper-V isolated containers within the guest VM. Nested virtualization adds complexity but provides the full range of container isolation options even in a virtualized container host environment. It’s important to ensure both the physical Hyper-V host and the guest VM are configured correctly for nested virtualization to function.

• SVVP Validated Hypervisor Host, Windows Server Guest, No Guest Hyper-V: If the VM host is a SVVP validated hypervisor (like VMware ESX, where Hyper-V is not supported as a guest hypervisor), and the guest OS is Windows Server, then only Windows Server containers are supported. Since Hyper-V is not an option within the guest VM on such hypervisors, Hyper-V isolation is not available. Support is limited to process-isolated Windows Server containers.

For more detailed information on SVVP validated hypervisors and the program itself, please refer to the “Welcome to the Windows Server Virtualization Validation Program” documentation. Understanding these configurations is crucial for architecting container solutions in virtualized environments and choosing the appropriate level of isolation and support based on the underlying infrastructure.

Supported Configurations for Windows 10 and Windows 11 Container Hosts¶

Microsoft extends container support to client operating systems like Windows 10 and Windows 11 Professional or Enterprise editions, but under specific conditions. These conditions are tailored for development and testing scenarios, rather than production deployments, which are typically targeted at Windows Server.

Microsoft supports containers on Windows 10 or Windows 11 Professional or Enterprise under the following conditions:

• Physical Computer and OS Version: The container host must be a physical computer running Windows 10 or Windows 11 Professional or Enterprise, with the Anniversary Update (version 1607) or later installed. Virtual machines running Windows 10 or 11 are not supported as container hosts in this context. The OS version requirement ensures compatibility with the necessary container features introduced in later Windows 10 releases.

• Hyper-V Installation: Hyper-V must be installed and enabled on the Windows 10 or Windows 11 system. Hyper-V is the virtualization technology that underpins container support on these client operating systems. It’s essential for providing the isolation and resource management required for containers.

• Container Type: Hyper-V Isolation (Default): The supported container type on Windows 10 and Windows 11 is Hyper-V isolation. This is the default and recommended isolation mode, providing enhanced security and separation for containers running on these client OSs. Process isolation for Windows Server containers is not fully supported on Windows 10/11 for production workloads.

• Docker Desktop for Windows Installation: Docker Desktop for Windows must be installed. This application is the officially supported distribution of Docker for Windows client operating systems. It provides the Docker Engine, Docker CLI, and other essential tools for managing containers. Docker Desktop is specifically designed for developers and small teams to get started with Docker and experiment with container-based applications locally. It bundles all necessary components for a seamless container development experience on Windows client. You can download and install Docker Desktop from Docker’s official website.

• Windows Server Containers in Process Isolation (Dev/Test Only): Starting with the Windows 10 and Windows 11 October 2018 Update, Microsoft no longer disallows users from running Windows Server containers in process isolation mode on Windows 10 and Windows 11 Enterprise or Professional. However, it’s crucial to understand that this support is explicitly for development or testing purposes only, and not for production workloads. Process isolation on Windows 10/11 is not fully supported and may have limitations or stability issues in production scenarios. This allowance is primarily for developer convenience, enabling them to test Windows Server containers locally before deploying to a supported Windows Server environment. Refer to the FAQ for more details on this topic.

Microsoft explicitly does not provide support for the following configurations on Windows 10 and Windows 11 Professional or Enterprise:

• Docker Desktop Support: While Docker Desktop is required, Microsoft does not provide direct support for Docker Desktop itself. Support for Docker Desktop is provided by Docker through their community forums or commercial support channels. For issues related to Docker Desktop, users should consult the Docker Community Forums or Docker Support. Refer to the Docker Desktop for Windows FAQ for further information.

• Virtual Machines as Container Hosts: Running Windows Server containers or Hyper-V containers with isolation on virtual machines that are hosted on a Windows 10 or Windows 11 Professional or Enterprise system is not supported. To use containers within a virtual machine environment, the host operating system must be Windows Server, not Windows 10 or 11. Windows 10/11 container support is limited to physical machines.

• Full Support for Windows Server Containers: While Windows Server containers can work on Windows 10 or Windows 11, they are not fully supported for production workloads. The primary supported scenario on Windows 10/11 is Hyper-V isolation for development and testing. Process-isolated Windows Server containers are allowed for dev/test, but neither container type is intended for production use on these client OSs within Microsoft’s support policy. Production container deployments should target supported Windows Server environments.

Requirement for Container Hosts¶

There are specific system requirements that must be met for both Windows Server and Windows client operating systems to function effectively as container hosts. These requirements span hardware, software, and configuration aspects. Adhering to these requirements is essential for ensuring stability, performance, and supportability of your container environment.

For detailed information about requirements for container hosts, consult the following resources:

• Windows container requirements: This document provides a comprehensive overview of the general system requirements for running Windows containers across different Windows versions.

• System requirements for Hyper-V on Windows Server: If you plan to use Hyper-V isolation or utilize Hyper-V features for containers, ensure your Windows Server host meets the Hyper-V system requirements outlined in this document.

• Run Hyper-V in a Virtual Machine with Nested Virtualization: For scenarios involving nested virtualization, this document details the specific requirements and configurations needed to run Hyper-V within a virtual machine.

• Windows Containers on Windows 10: This guide focuses on the specific requirements and setup instructions for running Windows containers on Windows 10, including Docker Desktop installation and Hyper-V configuration.

• Docker Engine on Windows: This resource provides information on configuring the Docker Engine on Windows, including daemon configuration and management.

• Windows Container Version Compatibility: Understanding container version compatibility is critical. This document outlines compatibility considerations between container host OS versions and container image versions.

• Linux containers on Windows 10: While LCOW is deprecated on Windows Server, this document might still provide context for users who might be exploring Linux containers on Windows client systems (though focus on current support policies).

For broader information on virtualization requirements and compatibility issues, refer to the Windows Server Catalog: Server Virtualization Validation Program. This catalog lists SVVP validated hypervisors and provides details on validated configurations.

Hyper-V Isolated Container Requirements¶

Running Hyper-V isolated containers imposes additional requirements on the container host, primarily because the host must be capable of running Hyper-V itself. These requirements are essentially the same as the system requirements for running Hyper-V on Windows Server.

To summarize Hyper-V requirements for Windows Server:

• 64-bit Processor with Specific Capabilities:

  • Second-level address translation (SLAT): SLAT is a crucial processor feature required by the Windows hypervisor functionality. While the Hyper-V management tools do not strictly require SLAT, the hypervisor itself does.
  • Hardware-assisted virtualization: The processor must support hardware-assisted virtualization. This is typically available in processors that include virtualization extensions, specifically Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) technology. Ensure these features are enabled in the BIOS/UEFI settings.
  • Hardware-enforced Data Execution Prevention (DEP): DEP must be available and enabled in the hardware. For Intel systems, this is the XD bit (execute disable bit). For AMD systems, this is the NX bit (no execute bit). DEP helps prevent the execution of code from data pages, enhancing security.

• VM Monitor Mode Extensions: The processor must support VM Monitor Mode extensions, which are essential for the operation of Hyper-V and virtualization.

• RAM: A minimum of 4 GB of RAM is required. However, more memory is highly recommended, especially if you plan to run multiple containers or VMs concurrently. Adequate RAM is crucial for both the host operating system and all virtualized workloads.

• Virtualization Support in BIOS/UEFI: Virtualization support (Intel VT or AMD-V) must be explicitly enabled in the system’s BIOS or UEFI settings. This is often disabled by default and needs to be activated for Hyper-V to function.

For more detailed information on system requirements, consult the following resources:

• System requirements for Hyper-V on Windows Server: This document provides the definitive system requirements for running Hyper-V on Windows Server.

• Windows 10 Hyper-V System Requirements: This document outlines the specific system requirements for Hyper-V on Windows 10, which are generally similar to Windows Server requirements but may have slight variations.

• How to enable nested virtualization in an Azure VM: While focused on Azure VMs, this document can provide insights into nested virtualization requirements, even though nested virtualization in on-premises scenarios has its own complexities and requirements as detailed earlier.

Supported Container Images¶

Microsoft provides a selection of four base container images that serve as starting points for building custom container images. Each base image is based on a different type of Windows operating system, each with varying on-disk footprint and a distinct set of available Windows APIs. Choosing the right base image is crucial as it dictates the capabilities and limitations of your containerized applications.

For comprehensive information on these base images, refer to the “Container Base Images” documentation.

The four supported container base images are:

• Windows Server Core: This base image is designed to support traditional .NET Framework applications. It provides a substantial subset of the Windows Server API surface, making it suitable for migrating existing .NET Framework applications to containers. Windows Server Core is a balanced choice, offering a good compromise between footprint and compatibility for many enterprise applications.

• Nano Server: Nano Server is a lightweight, headless version of Windows Server. It is specifically built and optimized for .NET Core applications and modern cloud-native workloads. Nano Server has a significantly smaller on-disk footprint and reduced attack surface compared to Windows Server Core. It’s ideal for microservices and applications designed for containerization from the ground up, leveraging .NET Core’s cross-platform capabilities.

• Windows Server: This base image provides the full Windows Server API set. It offers the highest level of compatibility with Windows applications, including those that rely on a broader range of Windows features and APIs not available in Windows Server Core. The Windows Server base image is suitable for applications with complex dependencies or those that require the complete Windows Server environment within a container. However, it also has the largest footprint among the base images.

• Windows IoT Core: Windows IoT Core is a specialized version of Windows designed for Internet of Things (IoT) applications. This base image is purpose-built for IoT scenarios and applications running on embedded devices or edge computing platforms. It is optimized for resource-constrained environments and IoT-specific functionalities. It is not intended for general-purpose server applications.

Container Base OS Images that are Supported on Windows Container Hosts¶

As previously outlined in the “Supported container hosts” section, not all host operating systems support both Windows Server containers and Hyper-V isolated containers equally. Similarly, the choice of base image also influences the supported container types. Certain base images are better suited for specific containerization modes or host operating systems.

The following table details the supported container types for each base image on different host operating systems:

Container host OS	Windows Server Core container base image	Nano Server container base image	Windows container base image	Windows IoT Core container base image
Windows Server 2016 or 2019 Standard or Datacenter	Windows Server containers and Hyper-V containers with isolation	Windows Server containers and Hyper-V containers with isolation	Windows Server containers and Hyper-V containers with isolation	Not supported
Windows 10 Professional or Enterprise	Hyper-V containers with isolation and Windows Server containers for dev/test	Hyper-V containers with isolation and Windows Server containers for dev/test	Hyper-V containers with isolation and Windows Server containers for dev/test	Not supported
Windows IoT Core	Not supported	Not supported	Not supported	Windows Server containers

Key Observations from the Table:

• Windows Server Hosts: Windows Server 2016 and 2019 (Standard or Datacenter editions) offer the broadest support. They can run both Windows Server containers (process isolation) and Hyper-V isolated containers using Windows Server Core, Nano Server, and Windows container base images. Windows IoT Core base image is not supported on these server OSs.

• Windows 10/11 Hosts: Windows 10 and Windows 11 Professional or Enterprise are primarily intended for Hyper-V isolated containers. While they can run Windows Server containers (process isolation) for development and testing, this is not a fully supported production scenario. Similar to Windows Server, Windows 10/11 hosts support Windows Server Core, Nano Server, and Windows container base images but not Windows IoT Core.

• Windows IoT Core Hosts: Windows IoT Core as a container host is highly specialized. It only supports the Windows Server container type (process isolation) and only when using the Windows IoT Core base image. It does not support Hyper-V isolation or the other base images (Windows Server Core, Nano Server, Windows container base image). This reflects its focus on lightweight, resource-constrained IoT scenarios.

When planning container deployments, especially across different versions and releases of Windows container hosts, it is crucial to consider the versions and releases of the container images as well. Container features may not always be backward compatible. Newer container base images might not function correctly on container hosts with older operating system versions. Refer to the “Windows Container Version Compatibility” documentation for detailed compatibility information.

Support for Container Workloads¶

Microsoft provides full support for the container base images it offers, as detailed in the “Supported container images” section. This support covers the base operating system within the container image and its core functionalities.

For support regarding Microsoft applications running within containers, such as IIS, SQL Server, and .NET applications, consult the Microsoft repository on Docker Hub. This repository provides guidance and support information specific to each Microsoft container image. It’s the primary source for understanding the support scope and best practices for running Microsoft applications in containers.

Note: If you are migrating a custom application or a third-party application to Windows Server containers using the Windows Server Core image and encounter issues related to missing .DLLs or other components in the Windows Server Core base image, consider trying the Windows Server container image. The Windows Server container image provides a more extensive Windows API set compared to Windows Server Core, which might resolve dependency issues for some applications.

Important Guidance on .DLLs: Avoid directly copying .DLL files from the container host to the Windows Server Core base image. This practice is strongly discouraged as it can lead to application instability and unpredictable behavior. Instead, Microsoft provides certain component .DLLs in the form of Redistributable packages. Download these Redistributable packages from the official Microsoft Download Center and install them within your container image using a Dockerfile. This ensures a supported and consistent approach for including necessary components.

It’s important to note that there is no single, definitive list of which .DLLs are available as Redistributable packages. You may need to research and check the Microsoft Download Center for specific component requirements.

For general guidance on migrating legacy applications to containers, refer to the “Lift and shift to containers” documentation. This resource provides strategies and best practices for containerizing existing applications.

Supported Network Configurations¶

Microsoft fully supports the Windows container networking functionality. This encompasses the underlying infrastructure and components responsible for container networking within Windows environments.

The key components of Windows container networking include:

• Host Networking Service (HNS): HNS is a Windows service responsible for network management in container environments. It handles network creation, policy enforcement, and overall network orchestration for containers.

• Host Compute Service (HCS): HCS is another core Windows service focused on container lifecycle management. While HNS manages networking, HCS is responsible for creating and managing containers themselves, including their compute resources.

HNS and HCS work in tandem. HCS creates containers, and HNS then attaches network endpoints to these containers, connecting them to the desired networks.

Additionally, Microsoft supports a range of container network drivers. These drivers define different network topologies and connectivity models for containers. Supported network drivers include:

• NAT (Network Address Translation)
• Transparent
• Overlay
• L2Bridge
• L2Tunnel
• Host

For detailed descriptions of each of these network drivers and their topologies, refer to the “Windows Container Network Drivers” documentation.

It’s also important to be aware of unsupported features and network options within Windows container networking. Consult the article “Unsupported features and network options” for a list of limitations and unsupported configurations.

Supported Service Accounts for Containers¶

Microsoft supports Active Directory group Managed Service Accounts (gMSA) for containers. gMSA provides a more secure and manageable way to handle service accounts for applications running in containers, especially in domain environments.

While containers themselves cannot be directly domain-joined, gMSA bridges this gap. gMSA supports both non-domain-joined and domain-joined container hosts. This flexibility allows organizations to leverage gMSA even in environments where the container hosts are not part of an Active Directory domain.

By utilizing gMSA, individual Windows Server containers and the services they host can be configured to use a specific gMSA as their domain identity. This means that any service running within the container under the Local System or Network Service accounts will inherit the Windows Server container’s gMSA identity, similar to how services on a domain-joined host use the host’s domain identity. This simplifies authentication and authorization for containerized applications interacting with domain resources.

For detailed instructions on setting up and using gMSA for Windows containers, refer to the “Create gMSAs for Windows containers” documentation.

Supported Endpoint Security Options for Containers and Container Hosts¶

Windows Defender is optimized to protect container hosts and is fully supported in this role. It provides essential endpoint protection for the underlying container infrastructure. However, Microsoft does not support running Windows Defender inside Windows Server containers. Running a full-fledged anti-virus solution within each container is generally not recommended due to performance overhead and management complexity. The focus is on securing the container host itself.

When using third-party endpoint security/anti-virus software, it is crucial to verify with the vendor that Windows Server containers are explicitly supported. Consult the vendor’s public documentation for recommendations and any necessary exclusions or configurations specific to container environments. Properly configuring third-party security software is essential to avoid conflicts or performance issues in containerized environments.

Refer to the “Anti-virus optimization for Windows Containers” documentation for general best practices and guidance on optimizing anti-virus solutions in container environments.

Supported Container Runtime on Windows Server¶

Mirantis Container Runtime (MCR) is the recommended and supported container runtime interface for creating, managing, and running Windows Server containers on Windows Server. MCR is specifically engineered for Windows Server environments and provides a robust and supported platform for container operations. For more information about MCR and its features, visit the Mirantis website.

For the recommended and supported installation method of MCR on Windows Server, consult the “Get Started: Prep Windows for containers” documentation. Following the recommended installation procedure ensures a properly configured and supported container runtime environment.

Important Support Transition: It’s crucial to note a significant change in support responsibility for MCR. After April 30, 2023, Microsoft is no longer the first point of contact for customers experiencing issues with Mirantis Container Runtime on Windows Server. Customers are now required to engage Mirantis directly for initial support.

For further details regarding this support transition, refer to the “Message from Mirantis”.

Key points regarding the Mirantis Container Runtime support transition:

1. Microsoft provided support for Mirantis Container Runtime until April 30, 2023.
2. Customers are licensed to continue running the number of copies of Mirantis Container Runtime they obtained before April 30, 2023, in perpetuity, but cannot acquire new licenses or expand existing deployments through Microsoft after this date.
3. After April 30, 2023, customers will no longer receive support, updates, or patches for the Mirantis container runtime from either Microsoft or Mirantis unless they have a direct support agreement with Mirantis.
4. Customers can purchase a license for a fully supported version of Mirantis Container Runtime directly from Mirantis at any time to ensure continued support and updates.

ContainerD: ContainerD is presented as an open-source, industry-standard container runtime supported by the community. While ContainerD can be used on Windows Server to create, manage, and run Windows Server containers, Microsoft does not provide direct support for ContainerD on Windows Server. Support for ContainerD is community-driven.

For any issues or questions related to ContainerD on Windows Server, users are directed to the GitHub community. The GitHub ContainerD project is the primary platform for community support, issue reporting, and feature requests.

Supported Container Orchestrators¶

Several container orchestrators are compatible with Windows Server containers. However, it’s essential to understand the support boundaries for each orchestrator. Before engaging Microsoft support for orchestrator-related issues, it’s generally recommended to first consult with the orchestrator vendor for initial troubleshooting and guidance.

Azure Kubernetes Service on Azure Stack HCI (AKS-HCI) or Windows Server: AKS-HCI and AKS on Windows Server are on-premises implementations of Azure’s flagship container orchestration service, Azure Kubernetes Service (AKS). These solutions automate the deployment, scaling, and management of containerized applications in on-premises datacenters. AKS simplifies the process of hosting both Linux and Windows containers within your local infrastructure.

Microsoft provides end-to-end support for Azure Kubernetes Service on Azure Stack HCI or Windows Server, including single-node deployments without high availability. This comprehensive support makes AKS-HCI and AKS on Windows Server a fully supported option for on-premises Windows container orchestration.

Limitations of Microsoft Support for AKS-HCI/AKS on Windows Server: Microsoft support does not extend to the following areas:

• Custom application code: Issues related to the application code running within containers are the responsibility of the application developer or vendor.
• Non-in-box system services or drivers: Support is limited to the standard system services and drivers included with Windows Server and AKS-HCI/AKS on Windows Server. Custom or third-party services and drivers within containers or container hosts are not directly supported by Microsoft in this context.
• Unsupported container base images: Microsoft only supports its own provided container base images (Windows Server Core, Nano Server, Windows Server, Windows IoT Core). Container base images not supported by Microsoft (such as Nginx) or those not listed in the supported add-ons list are outside the scope of Microsoft support.

For detailed information on support policies specifically for AKS hybrid solutions, refer to the “Support policies for AKS hybrid - AKS hybrid | Microsoft Learn” documentation.

Azure Kubernetes Service Edge Essentials (AKS EE): AKS Edge Essentials is another on-premises Kubernetes implementation from Azure, designed for edge computing scenarios. It provides a lightweight Kubernetes distribution with a small footprint and simplified installation process, making it suitable for deploying Kubernetes on PC-class or “light” edge hardware.

Microsoft offers end-to-end support for Azure Kubernetes Service Edge Essentials, with similar limitations as AKS-HCI/AKS on Windows Server.

Limitations of Microsoft Support for AKS EE: Microsoft support for AKS Edge Essentials excludes the following:

• Custom application code
• Non-in-box system services or drivers
• Unsupported container base images (e.g., Nginx or versions/base images not in the supported add-ons list).

Again, for detailed support policies for AKS hybrid solutions, consult the “Support policies for AKS hybrid - AKS hybrid | Microsoft Learn” documentation.

Azure Kubernetes Service (AKS) in Azure: Azure Kubernetes Service (AKS) in the Azure cloud is Azure’s primary managed Kubernetes service. Customers can create Windows Server-based node pools within an AKS cluster to run their Windows containers in Azure. AKS in Azure is a fully supported service. Any issues or questions related to AKS in Azure should be reported through the “Help + Support” section within the Azure portal.

Kubernetes (Open Source): Kubernetes is an open-source container orchestration platform that supports Windows Server containers on Windows Server 2019 and higher, starting with Kubernetes version 1.14. Kubernetes offers broad community support and is a widely adopted orchestration platform.

For more information on Windows support in Kubernetes, refer to the Kubernetes documentation: “Intro to Windows support in Kubernetes” and “Support Functionality and Limitations”. For getting started with Kubernetes on Windows, see “Kubernetes on Windows”.

For issues and questions specifically related to open-source Kubernetes, consult the Kubernetes community resources and documentation, particularly the “Reporting Issues and Feature Requests” section in the Kubernetes documentation.

Microsoft Support Scope for On-Premises Kubernetes: Microsoft provides support only for Windows nodes participating in an on-premises Kubernetes cluster. Microsoft support does not cover the following aspects of on-premises Kubernetes deployments:

• Setting up and configuring Linux nodes in a mixed-OS Kubernetes cluster.
• Kubernetes binaries themselves (the core Kubernetes components).
• Linux containers running within the Kubernetes cluster.
• Kubernetes plug-ins (networking, storage, etc.).

Any questions or issues related to these unsupported items should be addressed to the relevant Kubernetes community forums or GitHub communities.

Azure Service Fabric: Azure Service Fabric is a fully supported platform for orchestrating microservices and containerized applications, both in Azure and on-premises. All issues or questions regarding Azure Service Fabric should be directed to Azure support through the “Help + Support” section in the Azure portal. For more information about Service Fabric, see “Introducing Service Fabric cluster resource manager” and “Service Fabric and containers”.

Docker Swarm: Docker Swarm is a container orchestration feature integrated within Mirantis Container Runtime. It enables the creation, management, and running of Windows Server containers in mixed-node environments comprising both Linux and Windows hosts. Docker Swarm is fully supported by Mirantis. For issues or questions related to Docker Swarm, Mirantis support should be the initial point of contact. Mirantis support will advise customers on whether Microsoft support should be engaged if the issue is determined to be related to Windows Server itself. For details on using Docker Swarm with Windows Server containers, see “Getting started with swarm mode” and the “Swarm mode overview” documentation on the Mirantis website.

Moby Project: Moby is an open-source project that serves as the upstream project for Docker and related container technologies. It is intended for engineers, integrators, and enthusiasts who want to modify, experiment with, or build container-based systems. For more information, see the Moby project on GitHub.

Microsoft does not provide support for Moby in a standalone environment (a single-node container host running Windows Server). All questions and issues related to Moby in standalone setups should be raised within the Moby project on GitHub.

---

We hope this detailed overview of the support policy for Windows Server containers in on-premises scenarios is helpful for your planning and deployment efforts. If you have any further questions or insights, please feel free to leave a comment below!