The solution to ‘my version of Windows Server is about to lose support’ used to be ‘upgrade to a newer version’. But if you’ve carried on running an old version, such as Windows Server 2008 or 2008 R2, it’s probably not because you didn’t want to take the time to upgrade. Most likely it’s because you were running line-of-business applications that didn’t get any better on a newer OS, so the cost and disruption of upgrading outweighed the security benefits.
SEE: 250+ tips for telecommuting and managing remote workers (TechRepublic Premium)
Microsoft has been pushing organisations to modernise those server applications to run in containers — perhaps adding new features, but definitely making them more portable so it’s easier to keep the OS they’re running on up to date. The six-monthly Semi-Annual Channel (SAC) releases of Windows Server are where the updates to that container platform show up quickest, so you’re unlikely to experience the cognitive dissonance of moving from Windows Server 2008 to Windows Server 2004. But those who have already started work on modernising server apps will see some welcome improvements in this new release, especially for .NET.
The emphasis on reducing the download size of Windows Server container images continues (see chart, below): Windows Server 2004 is about 20% smaller than with WS 1909; the on-disk size is also smaller — just under 4GB instead of slightly less than 5GB. That makes it faster to download a container and deploy it.
A lot of the space saving comes from moving most of the NGEN performance optimisation from the Server Core image to the .NET Framework runtime image. Windows Server comes with .NET native binaries precompiled with NGEN, which makes them faster but also makes the image size larger. The Server Core image now has a much smaller set of precompiled binaries — just the x86 and X64 versions of mscorlib.dll, System.dll and System.Core.dll, along with a serviced version of the .NET Framework.
Even with the extra NGEN files, the .NET Framework image is also smaller. Partly that’s because many traditional Windows Server applications are ASP.NET web applications and the NGEN optimisation is now targeted to ASP.NET apps and PowerShell scripts, and partly because the image is now built to avoid the bloat you get by updating files through the Dockerfile that builds the image (which adds multiple copies of the file). Instead of installing and then patching the .NET Framework, the image loads the Windows Server Core to get the .NET Framework and then uses NGEN to pre-compile only the 64-bit assemblies for PowerShell and ASP.NET.
Although it’s not tied to Windows Server 2004, Windows Admin Center (WAC) also now makes it easier to work with containers on Windows Server.
In the past, Microsoft has put a lot of emphasis on the developer tools for building and debugging apps in containers, but that didn’t help sysadmins who were used to providing a VM infrastructure to run applications. WAC has tools for monitoring and troubleshooting containers running on Windows Server, but until now it didn’t have the tools to move existing apps into containers.
There’s now an extension that enables WAC to pull container images from container registries like Docker Hub, spin up containers (setting options like CPU and RAM allocation, environment variables and persistent storage in much the same way as you would for VMs), create new container images and push them to Azure Container Registry (or other registries) so you can use them from different container hosts.
The extension is available on the Insider Feed, although you can use it with release versions of WAC as well: turn this on under Settings / Extensions / Feeds and add the feed https://aka.ms/wac-insiders-feed, then pick the Containers extension from the list of available extensions. You’ll see the new features under Server Manager when you target a container host with Docker installed.
SEE: 5 developer interview horror stories (free PDF) (TechRepublic)
Initially, creating new images is restricted to containerising IIS Web Applications, including static web applications that don’t depend on frameworks and ASP.NET applications where you have access to the Visual Studio solution for the app. WAC will support more application types for containerisation in future: .NET and Java applications would be logical additions, as would SQL Server applications given that SQL Server itself is already available through containers.
You can incorporate PowerShell scripts for configuration, and you can use WAC to update an existing Dockerfile (if you’ve created a container for a previous version of the application and need to rebuild it for either a new OS or a new version of the application, for example). And rather like graphical admin tools for Windows Server and Exchange that also created a PowerShell script, you could copy to use for future automation and to help admins learn PowerShell, you can see a preview of the Dockerfile in WAC as you fill in the configuration. That will help admins become more familiar with the way a Dockerfile works, without forcing them to pick up new tools to work with the containers that are becoming an important Windows Server workload.
Before planning Windows Server 2004 installations, check whether you’re using Parity Storage Spaces; upgrades to this release are blocked on some hardware configurations because those storage partitions may show as RAW space in Disk Manager and running CHKDSK to fix that can cause data loss. If you’ve already upgraded to Windows Server 2004 and see the problem, Microsoft advises setting Parity Storage Spaces to read-only until it releases a fix. From an admin PowerShell console, run Get-VirtualDisk | ? ResiliencySettingName -eq Parity | Get-Disk | Set-Disk -IsReadOnly $true.