Discover the New Era of Windows Server 2025 Nano Server Containers
Overview Today, we’re excited to announce a new era of Windows Server containers with more powerful Windows Server 2025 Nano Server containers. Windows Server containers have long been a go-to solution for delivering lightweight, scalable applications. However, users working with Nano Server containers have traditionally faced a trade-off between efficiency and functionality. While Nano Server’s minimal footprint made it ideal for resource-constrained environments, it lacked key features required by modern applications. In this blog, we explore how the Windows Server 2025 Nano Server container addresses these challenges, bringing a new level of flexibility and functionality with the introduction of Features on Demand (FoD) support for Nano Server containers. When Efficiency Limits Functionality: Overcoming Nano Server’s Trade-Offs Nano Server was designed with a singular focus: maximum efficiency through a minimal footprint (typically around 175MB compressed). This approach reduces resource consumption, minimizes attack surfaces, and accelerates deployment. However, such minimalism comes with trade-offs. When an application requires functionality not included in the Nano Server image—such as 32-bit (WoW64) application support, IIS components, or PowerShell—users have traditionally had to switch to the larger Windows Server Core container image. Although Server Core offers broader compatibility, it does so at the expense of a significantly larger size (around 2GB compressed and potentially growing with updates). These limitations made Nano Server less suitable for workloads that demand additional features or legacy compatibility, despite its impressive performance and efficiency. Introducing Features on Demand (FoD) Support To overcome Nano Server's limitations without compromising its hallmark lightweight design, Windows Server 2025 introduces Features on Demand (FoD) support for Nano Server containers. FoD offers a dynamic approach to container image management, allowing developers to include only the specific capabilities they need—such as 32-bit (WoW64) application support—during the container build process. By avoiding the need to bundle all features into a single pre-installed image, this model preserves the minimal footprint of Nano Server while enabling broader application compatibility. The underlying technology not only resolves current compatibility challenges but also lays the groundwork for future innovations in Windows containers. As the platform evolves, FoD will enable new roles and capabilities, empowering users to incorporate only what is necessary, maintain optimized images, and unlock greater flexibility with future releases. Key Benefits of Features on Demand Reduced Image Footprint and Faster Pull Times: By excluding optional features from the base image, the initial download and storage size remain minimal, leading to quicker pull times and faster deployment. Enhanced Density and Performance: Smaller images consume less memory and disk space, allowing a higher density of containers to run on the same infrastructure, which improves overall application performance. Granular Control Over Features: Users can precisely select and add only the specific components their applications need, resulting in highly tailored and optimized container images. This also improves security by reducing the attack surface. Cost Optimization: Maintaining smaller image sizes by including only the necessary features can lead to tangible cost savings in cloud environments. Addressing 32-bit Application Support Through this investment, we’ve also addressed one of the most significant limitations of the original Nano Server container image: its inability to run 32-bit applications. This limitation arose from the deliberate design choice to minimize the image footprint, as supporting 32-bit applications requires additional libraries and components. With Windows Server 2025, users can now optionally add the necessary components for running 32-bit applications to the Nano Server container image as needed. This provides a more optimized approach compared to relying on the larger, monolithic Server Core image for all workloads, making Nano Server a viable option for a wider range of applications, including those with legacy dependencies. Integration and Use Cases The Features on Demand (FoD) capability in Windows Server 2025 Nano Server containers leverages the existing Windows FoD infrastructure. It utilizes tools like Deployment Image Servicing and Management (DISM) and PowerShell cmdlets to manage the installation and removal of optional features in Windows images. For containerized environments, these tools interact with the container runtime to seamlessly add necessary feature packages to the Nano Server base image. In addition to enabling 32-bit application support, FoD also allows for the inclusion of specialized server roles or features that were previously unavailable in Nano Server. These include minimal IIS components for hosting web applications or specific networking functionalities. Features on Demand for Nano Server Containers Feature Name Capability Name (Example) Description Use Case 32-bit Application Compatibility Microsoft.NanoServer.Datacenter.WOWSupport Enables running 32-bit applications. Running legacy applications in a lightweight container. Windows Management Instrumentation (WMI) Microsoft.NanoServer.WinMgmt Enables basic WMI functionality. Obtain data through queries and enumerations. Minimal IIS Components Microsoft.NanoServer.IIS Enables basic web server functionality. Hosting lightweight web applications. Getting Started with FoD Support in Nano Server Ready to try Features on Demand with the Windows Server 2025 Nano Server image? Here’s how to get started: Prepare the environment — Ensure that the Windows container host is properly configured and ready for building containers. Create an installation script — Write a batch file containing the DISM commands to install the required FoDs. In this example, the script installs Microsoft.NanoServer.Datacenter.WOWSupport to enable WOW64 support. Save the file as install_wowsupport.cmd: @echo off REM FoDs such as Microsoft.NanoServer.Datacenter.WOWSupport will trigger a request for reboot. REM For those FoDs, DISM will exit with 3010 which must be handled to prevent the batch from exiting with a non-zero status. REM Additionally we must supply the /NoRestart argument to suppress the reboot prompt. DISM /Online /Add-Capability /CapabilityName:Microsoft.NanoServer.Datacenter.WOWSupport /NoRestart if errorlevel 3010 ( echo The specified optional feature requested a reboot which was suppressed. exit /b 0 ) NOTE: The FoD name used with the /CapabilityName parameter should match one of the available options which can be obtained using DISM from inside the Nano Server container. Access to Windows Update is required for the Nano Server container to download and install the specified FoD. 3. Update the Dockerfile — The following Dockerfile example adds the batch script and installs the specified FoD during the container build process: FROM mcr.microsoft.com/windows/nanoserver:ltsc2025 WORKDIR /install COPY install_wowsupport.cmd . RUN install_wowsupport.cmd # Download tools to be used for the sample workload RUN curl -L https://download.sysinternals.com/files/PSTools.zip > PSTools.zip RUN mkdir pstools RUN tar -xf PSTools.zip -C pstools 4. Build and tag the container image — Use the following command to build the container image and apply a custom tag: docker build -t <newname:tag> . 5. Validate using a 32-bit sample workload — Create and run a new container from the updated image to verify that the configuration is correct. In this example, validation is done by running the 32-bit version of the Sysinternals PSInfo tool (downloaded in step 3) using the following command to observe Nano Server’s WOW64 support: PsInfo.exe -accepteula Closing With the introduction of Features on Demand in Windows Server 2025 Nano Server containers, users now have the best of both worlds: a minimal footprint with the flexibility to add only the features needed for their specific workloads. This innovation marks a significant leap forward, delivering enhanced app compatibility, all while retaining Nano Server’s efficiency. And this is just the beginning—FoD unlocks exciting possibilities for the future of Windows containers. As always, your feedback is invaluable in shaping the future of Windows Containers. We encourage you to share your experiences and insights through the Windows Container GitHub Community.Announcing Windows Container on Azure Kubernetes Service Demos
Today I am very happy to announce the release of Windows Container on Azure Kubernetes Service Demos. This Demos repo is a collection of demos to show how you can modernize Windows Server applications with Windows containers running on Azure Kubernetes Service (AKS). GitHub Repo: Windows Container on Azure Kubernetes Service Demos
Announcing Active Directory Identity Improvement on AKS on Azure Stack HCI
We’re very pleased to announce that Group Managed Service Account (gMSA) for Containers with non-domain joined host solution is now available in the recently announced AKS on Azure Stack HCI Release Candidate! “gMSA with non-domain joined host” vs. “gMSA with domain-joined host” gMSA with non-domain joined host gMSA with domain-joined host Credentials are stored as K8 secret and authenticated parties can retrieve the secret. These creds are used to retrieve the gMSA identity from AD. This eliminates the need for container host to be domain joined and solves challenges with container host updates. Updates to Windows container host can pose considerable challenges. All previous settings need to be reconfigured to domain join the new container host. Simplified end-to-end gMSA configuration process by build-in cmdlets In AKS on Azure Stack HCI, even though you don't need to domain join Windows worker nodes anymore, there are other configuration steps that you can't skip. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC). We provide a few PowerShell cmdlets to simply the end-to-end experience. Please refer to Configure group Managed Service Accounts with AKS on Azure Stack HCI - AKS-HCI | Microsoft Docs. Getting started We have provided detailed documentation on how to integrate your gMSA with containers in AKS-HCI with non-domain joined solution. Preparing gMSA in domain controller Configure group Managed Service Accounts with AKS on Azure Stack HCI - AKS-HCI | Microsoft Docs Prepare the gMSA credential spec JSON file (This is a one-time action. Please use the gMSA account in your domain) Install webhook, add Kubernetes secret and add gMSA Credential Spec can be finished by three cmdlets Deploy your application. As always, we love to see you try it out, and give us feedback. You can share your feedback at our GitHub community Issues · microsoft/Windows-Containers (github.com) , or contact us directly at win-containers@microsoft.com. Jing Twitter: https://twitter.com/JingLi00465231
