First Look: Down to the Server Core
The Windows Server 2016 "Insider" preview Build 16237 of the fall update only supports Server Core deployments and a stripped-down Nano Server option with improvements to Hyper-V, RDMA for trusted guests and support for persistent memory.
Windows Server is the latest Microsoft software offering to join the rapid release cycle of upgrades. Until last year's rollout of Windows Server 2016, Microsoft typically upgraded the server OS every three years and those who wanted to take advantage of the features and capabilities within the new version would have to license the new release and then begin the upgrade process.
Microsoft's new approach to upgrading Windows Server falls in line with Microsoft's plan to release updates to Windows 10 and Office 365 Pro Plus each spring and fall. The company has begun referring to this new approach as its semiannual channel release cycle. However, only those organizations with a Software Assurance plan will be eligible to receive these biannual updates. At the recent Build Conference in Seattle, Microsoft said it was eliminating the option to run Nano Server as a bare metal or virtual machine (VM) OS. Instead, the Nano option is a stripped-down footprint relegated only for the deployment of container-based runtimes. Microsoft is recommending Server Core configurations for those seeking small-footprint compute, VM and storage clusters.
Not only is Microsoft recommending Server Core configurations, but the recently released first Technical Preview showcasing the Windows Server 2016 fall update, called Build 16237, only supports that mode of deployment (see Figure 1). It doesn't offer the option to deploy Windows Server with a GUI.
It remains to be seen whether the elimination of the desktop experience will remain permanent. Countless reports have indicated that the Windows Server GUI is about to become a thing of the past, but Microsoft has not yet made any definitive statements as of early August. Out of curiosity, I tried installing the Desktop Experience through PowerShell, but this build doesn't offer that option.
The last three Windows Server releases (Windows Server 2012, 2012 R2 and 2016) featured substantial Hyper-V improvements. Windows Server 2012 introduced an almost completely revamped Hyper-V and Windows Server 2012 R2 built onto those improvements. Windows Server 2016 addressed some of the security shortcomings in Hyper-V by introducing new features, such as shielded VMs. The preview introduces additional improvements to Hyper-V.
One is a Battery Passthrough feature for Hyper-V VMs. This feature allows you to force a VM to reflect the same battery state as the host server. It's worth noting that Battery Passthrough doesn't happen automatically. Instead, the Set-VM cmdlet has been extended with a new BatteryPassThroughEnabled flag. Setting this flag to $True turns on the Battery Passthrough feature for the specified VM.
I admit I initially didn't initially see much value in this feature. It appeared geared toward developers who work from laptops and wanted an easy way to monitor the amount of battery power they have remaining. Upon further evaluation, though, it was evident that it has practical use.
The Windows 10 taskbar displays the battery state through an icon you can click on to get more detailed information (see Figure 2). What makes this screen capture somewhat unique is it was taken on a desktop computer, not a laptop.
My desktop PC is connected to a UPS, but Windows 10 reports battery information as if I were working from a laptop. With that in mind, consider the fact that Windows Server contains Group Policy settings (see Figure 3) that allow you to automatically shut down a system if its battery is low. Although these types of Group Policy settings have been traditionally used to initiate the graceful shutdown of laptops when their batteries run low, it's conceivably possible to force a graceful shutdown of Hyper-V VMs in a situation in which a power failure has occurred and the backup battery is running low.
Persistent Memory Support
Microsoft has also added persistent memory support for Hyper-V VMs through the use of non-volatile DIMMs. Non-volatile DIMMs are similar to the memory modules you're accustomed to, except they retain memory contents even when a power failure occurs. While resilience to power failures is a nice feature, it misses the bigger picture. Non-volatile DIMMs make RAM disks far more practical.
RAM disks are one of those technologies that has been around in one form or another for decades, but has periodically fallen in and out of fashion. System RAM is much faster than hard disk storage and, therefore, the performance of I/O-intensive workloads can be greatly improved by reserving a portion of a system's memory and treating it as if it were a disk. Back in the 1990s, for example, I had a PC with an extremely slow hard disk, so I got in the habit of using a RAM disk every time I played certain video games, because the games ran so much more smoothly from a RAM disk.
However, RAM disks were only a temporary structure. As soon as I turned off my PC, the RAM disk went away, and had to be created again the next time I needed it. Today, however, non-volatile DIMMs allow for the creation of persistent RAM disks. In fact, the newfound support in Hyper-V for non-volatile DIMMs might be better described as support for persistent RAM disks. Starting with Windows Server 2016 Build 16237, it's possible to create a RAM disk on non-volatile DIMM memory, format the RAM disk with NTFS and then use that disk for VM storage.
According to Microsoft, this involves a little bit more than just creating a virtual hard disk file on non-volatile memory. You'll also need to add a Virtual Persistent Memory (vPMEM) controller and a virtual device (vhdpmem) to the VM in order to use this feature.
Because RDMA allows for direct memory access (hence its name), there are security considerations you must consider. For this reason, Microsoft doesn't provide blanket RDMA capabilities for all guests. Instead, the administrator has the option to enable RDMA for trusted guests, while leaving RDMA disabled for all others.
According to Microsoft, guest RDMA is especially useful for guest file servers, because it can reduce storage latency, while also decreasing the CPU workload (guest RDMA doesn't use the CPU).
The new Windows Server Build 16237 also includes several networking-related improvements. Some of these improvements are related to software-defined networking (SDN), while others apply to networking in general. One of the main SDN enhancements is an improvement in the failover time for SDN gateways.
Microsoft has also made some security improvements to software-defined networks. Entire virtual network subnets can now be encrypted to prevent snooping by anyone who has physical access to the hardware on which the virtual network subnet resides. Microsoft even allows access control lists to be applied to infrastructure components on logical subnets.
When it comes to general networking, Microsoft has taken steps to improve network performance within the datacenter. According to Microsoft, single connection TCP and UDP traffic flowing across low-latency connections should see a 2x improvement in throughput. Furthermore, Microsoft is also implementing a default congestion control algorithm on high-speed networks.
Microsoft has also made some improvements to SSL-encrypted HTTP (HTTPS). Although not a lot of information is available right now, Microsoft notes Windows Server Build 16237 supports deterministic certificate updates for HTTPS, as well as SSL throttling, which should help ensure that those clients already connected continue to receive a good experience during traffic spikes.
Microsoft's decision to relegate the Nano Server configuration option to container runtimes has led to quite a bit of confusion and frustration. Nano Server was first introduced in the RTM release of Windows Server 2016, and initially seemed to be an attempt to create what Server Core should have been all along. Nano Server was designed to be an extremely lightweight, headless server OS. However, the problem was that Nano Server wasn't quite what people expected.
Many IT pros have told me they expected to be able to insert the Windows Server 2016 installation media, run Setup and choose Nano Server as an installation type, just as you can choose Server Core or Windows Server with the desktop experience. Unfortunately, Microsoft didn't make Nano Server deployments quite that easy. Rather than simply installing Nano Server, you had to build a Nano Server deployment.
Although there was a learning curve associated with deploying Nano Server, the process wasn't overly difficult. Even so, the process sometimes proved to be problematic on physical hosts due to the need for drivers. More important, Nano Server didn't support all of the Windows Server roles and features, so it was very limited in what it could be used for. Using Nano Server also introduced challenges associated with system management, backups and even patch management.
Nano Server was a good idea, but it was somewhat poorly implemented. Microsoft tried to make things easier on its customers by introducing a GUI-based Nano Server configuration tool, but apparently Microsoft determined these efforts were too little, too late. Going forward, Nano Server will only be available for use as a container OS.
In transitioning Nano Server to function solely as a container OS, Microsoft has trimmed down an already tiny OS by removing things such as Windows PowerShell and WMI. This, of course, raises the question of what you'll actually be able to use Nano Server for. According to Microsoft documentation, Nano Server will be optimized for running .NET Core applications (bit.ly/2fls2HH).
Observations and Impressions
The Windows Server Build 16237 preview reveals several key changes and enhancements to the server OS. The changes are largely positive in nature, but I'm disappointed in Microsoft's decision to degrade Nano Server to a container-only OS. While I agree that an extremely lightweight container OS is needed, I also believe Nano Server had its place and there's no reason why Microsoft couldn't have created both a container version and a standalone version of Nano Server.